SORT SUM Problem
Hi all, I should probably say "my problem with SORT SUM", as the real problem is not with SORT. So, I have an input file with a 100 byte record that has a dataset name on the first 44 bytes and a numeric value (UFF) on the last ten. I need to sum up those 10 last bytes by High Level Qualifier. My problem, after a few variations, is that I cannot get rid of the ICE152I 0 OVERFLOW DURING SUMMATION - RC=0 message. This is my latest try: //SYMNAMES DD * INP-DSN,01,44,CH INP-BYTE,91,10,UFF SKIP,1 FMT-HLQ,1,08,CH FMT-BYTE,*,08,BI TMP-BYT1,=,04,BI TMP-BYT2,*,04,BI //SYSINDD * INREC PARSE=(%01=(ABSPOS=1,ENDBEFR=C'.',FIXLEN=8)), OVERLAY=(FMT-HLQ:%01, TMP-BYT2:INP-BYTE) * SUM HLQ ALLOC SPACE SORT FIELDS=(FMT-HLQ,A) SUM FIELDS=(FMT-BYTE) OUTREC BUILD=(X, FMT-HLQ, X, FMT-BYTE,TO=ZD,LENGTH=16) /* The SORTOUT is deirected to SYSOUT and it looks something like this: COMUM9242510529872113 COMUM9242510529872114 COMUM9242510529872114 COMUM9242510529872114 COMUM9242510529871936 COMUM9242510529871936 COMUM9242510529872113 COMUM9242510529872113 COMUM9242510529872113 There are 26 of those when there should be only one (not counting the few hundreds more repetitions of several HLQs) So, what am I doing wrong? Your help will be, as usual, greatly appreciated, Jack -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT SUM Problem
Jack, The issue is you have NOT converted the UFF value to Binary before performing the SUM Here is the change you need (Untested) //SYSINDD * INREC PARSE=(%01=(ABSPOS=1,ENDBEFR=C'.',FIXLEN=8)), BUILD=(FMT-HLQ:%01, FMT-BYTE:INP-BYTE,TO=BI,LENGTH=8) SORT FIELDS=(FMT-HLQ,A) SUM FIELDS=(FMT-BYTE) OUTREC BUILD=(X, FMT-HLQ, X, FMT-BYTE,TO=ZD,LENGTH=16) /* Thanks, Kolusu DFSORT Development IBM Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C+ strange compile errors
David
Not Really understanding what you are suggesting is there another c++ compiler
on z/os I should be using ?
As I am using CCNDRVR
Are you saying that the standard template libraries functions such as map wont
work with CNNDRVR
As an aside the following statement compiled fine under MSVC or visual studio
auto ret = procpointer->extsymcollector->insert({ *s, *exsympointer });
while I had problems with CNNDRVR seems like it didn’t didn’t like the '{'
c89 which seems to run from a unix shell is the only other compiler I am aware
of
Thanks
---Original Message-
From: IBM Mainframe Discussion List On Behalf Of
David Crayford
Sent: Monday, January 30, 2023 9:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C+ strange compile errors
On 30/1/23 07:31, Joseph Reichman wrote:
> Please accept my apologies the program consisted of hundreds of lines
> which I complied cleanly using Visual studio.
>
>
>
> Obviously, there are difference not in ANSI C++ which I Think XL is at
> 20 but in the window types.
There are three IBM C/C++ compiler products that run on z/OS. XL C/C++ is
practically moribund. XL C++ implements a small subset of C++11 such as R-value
references but not the standard library. That's what you're using as it's the
only compiler with a JCL batch interface. All the others ship z/OS UNIX
binaries only. You can still compile programs in PDS libraries but nobody in
their right minds would want to do that in 2023.
xlclang/xlclang++ is a Clang/LLVM front end to the XL C++ back-end. It
implements the C11 and C++14 standards. It's 64-bit only.
Open XL C/C++ is a full blown port of Clang/LLVM and has partial support for
C++20 https://clang.llvm.org/cxx_status.html.
>
>
>
> To make the program compatible with types like DWORD I added typedef due to
> my oversight I forgot to end one with a semi colon which was right before
> the includes which caused one long error.
>
>
>
> Hope I didn't waste any one time.
>
>
The only person whose time you're wasting is your own by using the wrong
compiler (and IDE). Why are you pulling in all of the Windows API header
file crap? Visual Studio Community is an amazing product for writing
Windows programs in a multitude of languages but it's complete overkill
for editing a program to be run on z/OS. If you really must use VS then
configure it to use clang/LLVM
https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170.
You will then have a standard C/C++ environment without all the Windows
garbage. Extra features such as clang-tidy will lint your code for
errors as you type. My advice is to ditch VS for the much lighter weight
VS Code which supports more languages and is designed from the get-go to
be cross-platform.
>
> Thanks you.
>
>
>
> From: reichman...@gmail.com
> Sent: Wednesday, January 25, 2023 2:28 PM
> To: 'IBM Mainframe Discussion List'
> Subject: XL C\C+ strange compile errors
>
>
>
> Hi
>
>
>
> I have a very short C++ program compiling as /CXX which all it does is
> basically open a file
>
>
>
> I am getting a whole slew of errors but they are not from my program they
> are standard includes CEE.SCEEH.H(STDDEF) and in fact I didn't explicitly
> include them (maybe they got included by 2 includes that I included in my
> program of and
>
>
>
> Thing is I don't know why I am getting these errors they would seem to be
> okay for C++ such as "extern" and size_t
>
>
>
> Here is a screen shot of some of the errors
>
>
>
> "//'CEE.SCEEH.H(STDDEF)'", line 39.4: CCN5063 (S) The text "extern" is
> unexpecte"
>
> "//'CEE.SCEEH.H(STRING)'", line 119.51: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 120.54: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 121.60: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 122.45: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 125.14: CCN5040 (S) The text "__strlen" is
> unexpa
>
> ambiguous.
> "
>
> "//'CEE.SCEEH.H(STRING)'", line 130.58: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 131.58: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 132.64: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 144.51: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 146.57: CCN5063 (S) The text "size_t" is
> unexpec"
>
> "//'CEE.SCEEH.H(STRING)'", line 148.43: CCN5063 (S) The text "size_t" is
> unexpec"
>
>
>
>
>
> Here is partial list of my compile JCL
>
>
>
> * Top of Data *
>
> //JOER$ JOB 'ADCD V2R9','SYSPROG',NOTIFY=&SYSUID,REGION=0M
>
> //*
>
> //*---
>
> //* COMPILE STEP:
>
> //*---
Re: SORT SUM Problem
Thank you Sri. It was as simple as that. Many thanks Jack On Tue, 31 Jan 2023 at 12:46, Sri h Kolusu wrote: > Jack, > > The issue is you have NOT converted the UFF value to Binary before > performing the SUM > > Here is the change you need (Untested) > > //SYSINDD * > INREC PARSE=(%01=(ABSPOS=1,ENDBEFR=C'.',FIXLEN=8)), > BUILD=(FMT-HLQ:%01, >FMT-BYTE:INP-BYTE,TO=BI,LENGTH=8) > > SORT FIELDS=(FMT-HLQ,A) >SUM FIELDS=(FMT-BYTE) > OUTREC BUILD=(X, > FMT-HLQ, > X, > FMT-BYTE,TO=ZD,LENGTH=16) > /* > > Thanks, > Kolusu > DFSORT Development > IBM Corporation > > > > -- > 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
SMF puzzle
Hi all, I'm facing a problem with SMF that is completely unusual, and maybe you can enlight me. I do have a program that generates SMF records and it is possible to specify the SMF number of any choice (bigger than 127). The SMF record is issued using SMFWTM macro. I also have an IEFU83 and IEFU84 SMF exits and since SMFWTM is being used, IEFU83 will be lunched to intercept the previously generated SMF record. Since it is in test, the first thing IEFU83 does is to WTO the SMF type and subtype it is processing, for debugging purposes. Now comes the strange part. if the SMF number is between 128 and 205 (inclusive), the WTO is issued normaly, but if the SMF number is bigger than 205 it seems the exit is not invoked because no WTO is issued at all. The SMF is generated correctly because I can extract it from SYS1.MANx datasets. Here goes a piece of code of IEF83/4 to ilustrate. USING SMFRCD0,R9 * MAPS SMF RECORD HEADER DXSOTHR CLI SMF0RTY,128 * SMF SYSTEM RECORD (<128)? BL DXSTYSU * YES, CHECK TYPE/SUBTYPE/PROD BAS R8,DXMSG <=== TEMP * DISPLAY AND RETURN DXSTYSU DS 0H Are there any kind of restriction because it is completely crazy. Best Regards Ituriel do Nascimento Neto z/OS System Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF puzzle
Check your PARMLIB SMFPRMxx member to insure the higher number is processed. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, January 31st, 2023 at 8:29 AM, Ituriel do Neto <03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: > Hi all, > > I'm facing a problem with SMF that is completely unusual, and maybe you can > enlight me. > > I do have a program that generates SMF records and it is possible to specify > the SMF number > of any choice (bigger than 127). The SMF record is issued using SMFWTM macro. > > I also have an IEFU83 and IEFU84 SMF exits and since SMFWTM is being used, > IEFU83 will > be lunched to intercept the previously generated SMF record. > Since it is in test, the first thing IEFU83 does is to WTO the SMF type and > subtype it is processing, > for debugging purposes. > > Now comes the strange part. if the SMF number is between 128 and 205 > (inclusive), the WTO is > issued normaly, but if the SMF number is bigger than 205 it seems the exit is > not invoked because > no WTO is issued at all. > The SMF is generated correctly because I can extract it from SYS1.MANx > datasets. > > Here goes a piece of code of IEF83/4 to ilustrate. > > USING SMFRCD0,R9 * MAPS SMF RECORD HEADER > DXSOTHR CLI SMF0RTY,128 * SMF SYSTEM RECORD (<128)? > BL DXSTYSU * YES, CHECK TYPE/SUBTYPE/PROD > BAS R8,DXMSG <=== TEMP * DISPLAY AND RETURN > DXSTYSU DS 0H > > Are there any kind of restriction because it is completely crazy. > > Best Regards > > Ituriel do Nascimento Neto > z/OS System Programmer > > -- > 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: SMF puzzle
Mr Pinion, Thank you, but its not this problem. The SMFPRMxx is correct, otherwise the SMF record would not be generated. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em terça-feira, 31 de janeiro de 2023 10:48:01 BRT, rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> escreveu: Check your PARMLIB SMFPRMxx member to insure the higher number is processed. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, January 31st, 2023 at 8:29 AM, Ituriel do Neto <03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: > Hi all, > > I'm facing a problem with SMF that is completely unusual, and maybe you can > enlight me. > > I do have a program that generates SMF records and it is possible to specify > the SMF number > of any choice (bigger than 127). The SMF record is issued using SMFWTM macro. > > I also have an IEFU83 and IEFU84 SMF exits and since SMFWTM is being used, > IEFU83 will > be lunched to intercept the previously generated SMF record. > Since it is in test, the first thing IEFU83 does is to WTO the SMF type and > subtype it is processing, > for debugging purposes. > > Now comes the strange part. if the SMF number is between 128 and 205 > (inclusive), the WTO is > issued normaly, but if the SMF number is bigger than 205 it seems the exit is > not invoked because > no WTO is issued at all. > The SMF is generated correctly because I can extract it from SYS1.MANx > datasets. > > Here goes a piece of code of IEF83/4 to ilustrate. > > USING SMFRCD0,R9 * MAPS SMF RECORD HEADER > DXSOTHR CLI SMF0RTY,128 * SMF SYSTEM RECORD (<128)? > BL DXSTYSU * YES, CHECK TYPE/SUBTYPE/PROD > BAS R8,DXMSG <=== TEMP * DISPLAY AND RETURN > DXSTYSU DS 0H > > Are there any kind of restriction because it is completely crazy. > > Best Regards > > Ituriel do Nascimento Neto > z/OS System Programmer > > -- > 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: SMF puzzle
Are you checking the return code from WTO? Does the message show data from the SMF record or a boilerplate? The snippet looks fine. Show the code. On Tue, 31 Jan 2023 13:29:16 + Ituriel do Neto <03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: :>I'm facing a problem with SMF that is completely unusual, and maybe you can enlight me. :>I do have a program that generates SMF records and it is possible to specify the SMF number :>of any choice (bigger than 127). The SMF record is issued using SMFWTM macro. :>I also have an IEFU83 and IEFU84 SMF exits and since SMFWTM is being used, IEFU83 will :>be lunched to intercept the previously generated SMF record. :>Since it is in test, the first thing IEFU83 does is to WTO the SMF type and subtype it is processing, :>for debugging purposes. :>Now comes the strange part. if the SMF number is between 128 and 205 (inclusive), the WTO is :>issued normaly, but if the SMF number is bigger than 205 it seems the exit is not invoked because :>no WTO is issued at all. :>The SMF is generated correctly because I can extract it from SYS1.MANx datasets. :>Here goes a piece of code of IEF83/4 to ilustrate. :> USING SMFRCD0,R9 * MAPS SMF RECORD HEADER :>DXSOTHR CLI SMF0RTY,128 * SMF SYSTEM RECORD (<128)? :> BL DXSTYSU * YES, CHECK TYPE/SUBTYPE/PROD :> BAS R8,DXMSG <=== TEMP * DISPLAY AND RETURN :>DXSTYSU DS 0H :>Are there any kind of restriction because it is completely crazy. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF puzzle
I have done a small change, like below: USING SMFRCD0,R9 DXSOTHR CLI SMF0RTY,128 BL DXSTYSU WTO 'IEFU83 EXIT INVOKED' ** BAS R8,DXMSG <=== TEMP DXSTYSU DS 0H * And when SMF 205 is generated, the WTO is issued, while when it is time for 206, nothing is WTOed, but the SMF is generated. Really, really strange. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em terça-feira, 31 de janeiro de 2023 13:03:09 BRT, Binyamin Dissen escreveu: Are you checking the return code from WTO? Does the message show data from the SMF record or a boilerplate? The snippet looks fine. Show the code. On Tue, 31 Jan 2023 13:29:16 + Ituriel do Neto <03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: :>I'm facing a problem with SMF that is completely unusual, and maybe you can enlight me. :>I do have a program that generates SMF records and it is possible to specify the SMF number :>of any choice (bigger than 127). The SMF record is issued using SMFWTM macro. :>I also have an IEFU83 and IEFU84 SMF exits and since SMFWTM is being used, IEFU83 will :>be lunched to intercept the previously generated SMF record. :>Since it is in test, the first thing IEFU83 does is to WTO the SMF type and subtype it is processing, :>for debugging purposes. :>Now comes the strange part. if the SMF number is between 128 and 205 (inclusive), the WTO is :>issued normaly, but if the SMF number is bigger than 205 it seems the exit is not invoked because :>no WTO is issued at all. :>The SMF is generated correctly because I can extract it from SYS1.MANx datasets. :>Here goes a piece of code of IEF83/4 to ilustrate. :> USING SMFRCD0,R9 * MAPS SMF RECORD HEADER :>DXSOTHR CLI SMF0RTY,128 * SMF SYSTEM RECORD (<128)? :> BL DXSTYSU * YES, CHECK TYPE/SUBTYPE/PROD :> BAS R8,DXMSG <=== TEMP * DISPLAY AND RETURN :>DXSTYSU DS 0H :>Are there any kind of restriction because it is completely crazy. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- 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
OMVS
I need to move my SMPe from one LPAR to another. My concern are my MOUNTPOINTS. My current zFS is ETC with a mountpoint of /SERVICE/MVS1/etc Do I need to mount the MP and go create the /SERVICE/DEV1/etc Then UNMOUNT and MOUNT it again as /DEV1/etc Regards, Steve Beaver -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF puzzle
Exit IEFU86 is called first. Do you have a U86 exit doing something first? On Tue, Jan 31, 2023 at 12:30 PM Ituriel do Neto < 03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: > I have done a small change, like below: > > USING SMFRCD0,R9 > DXSOTHR CLI SMF0RTY,128 > BLDXSTYSU > WTO 'IEFU83 EXIT INVOKED' > ** BAS R8,DXMSG <=== TEMP > DXSTYSUDS0H * > > And when SMF 205 is generated, the WTO is issued, while when it is time > for 206, nothing is WTOed, but the SMF is generated. > > Really, really strange. > > Best Regards > > Ituriel do Nascimento Neto > z/OS System Programmer > > > > > > > Em terça-feira, 31 de janeiro de 2023 13:03:09 BRT, Binyamin Dissen < > bdis...@dissensoftware.com> escreveu: > > > > > > Are you checking the return code from WTO? > > Does the message show data from the SMF record or a boilerplate? > > The snippet looks fine. > > Show the code. > > On Tue, 31 Jan 2023 13:29:16 + Ituriel do Neto > <03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: > > :>I'm facing a problem with SMF that is completely unusual, and maybe you > can enlight me. > > :>I do have a program that generates SMF records and it is possible to > specify the SMF number > :>of any choice (bigger than 127). The SMF record is issued using SMFWTM > macro. > > :>I also have an IEFU83 and IEFU84 SMF exits and since SMFWTM is being > used, IEFU83 will > :>be lunched to intercept the previously generated SMF record. > :>Since it is in test, the first thing IEFU83 does is to WTO the SMF type > and subtype it is processing, > :>for debugging purposes. > > :>Now comes the strange part. if the SMF number is between 128 and 205 > (inclusive), the WTO is > :>issued normaly, but if the SMF number is bigger than 205 it seems the > exit is not invoked because > :>no WTO is issued at all. > :>The SMF is generated correctly because I can extract it from SYS1.MANx > datasets. > > :>Here goes a piece of code of IEF83/4 to ilustrate. > > :>USING SMFRCD0,R9 * MAPS SMF RECORD > HEADER > :>DXSOTHR CLI SMF0RTY,128 * SMF SYSTEM RECORD (<128)? > :>BLDXSTYSU * YES, CHECK > TYPE/SUBTYPE/PROD > :>BAS R8,DXMSG <=== TEMP * DISPLAY AND RETURN > > :>DXSTYSU DS0H > > :>Are there any kind of restriction because it is completely crazy. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > 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 > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS
I assume you're not zfs file sharing? I usually don't mount etc or dev unless I'm doing an upgrade, but if you're not sharing the /SERVICE/ filesystems then yes you need to create the mount points first - then remount them on the moved-to LPAR Carmen On 1/31/2023 12:56 PM, Steve Beaver wrote: I need to move my SMPe from one LPAR to another. My concern are my MOUNTPOINTS. My current zFS is ETC with a mountpoint of /SERVICE/MVS1/etc Do I need to mount the MP and go create the /SERVICE/DEV1/etc Then UNMOUNT and MOUNT it again as /DEV1/etc Regards, Steve Beaver -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Carmen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF puzzle
I would like to thank you all. As expected It was a logic error, before the piece of code shown. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em terça-feira, 31 de janeiro de 2023 15:58:01 BRT, Michael Babcock escreveu: Exit IEFU86 is called first. Do you have a U86 exit doing something first? On Tue, Jan 31, 2023 at 12:30 PM Ituriel do Neto < 03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: > I have done a small change, like below: > > USING SMFRCD0,R9 > DXSOTHR CLI SMF0RTY,128 > BL DXSTYSU > WTO 'IEFU83 EXIT INVOKED' > ** BAS R8,DXMSG <=== TEMP > DXSTYSU DS 0H * > > And when SMF 205 is generated, the WTO is issued, while when it is time > for 206, nothing is WTOed, but the SMF is generated. > > Really, really strange. > > Best Regards > > Ituriel do Nascimento Neto > z/OS System Programmer > > > > > > > Em terça-feira, 31 de janeiro de 2023 13:03:09 BRT, Binyamin Dissen < > bdis...@dissensoftware.com> escreveu: > > > > > > Are you checking the return code from WTO? > > Does the message show data from the SMF record or a boilerplate? > > The snippet looks fine. > > Show the code. > > On Tue, 31 Jan 2023 13:29:16 + Ituriel do Neto > <03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: > > :>I'm facing a problem with SMF that is completely unusual, and maybe you > can enlight me. > > :>I do have a program that generates SMF records and it is possible to > specify the SMF number > :>of any choice (bigger than 127). The SMF record is issued using SMFWTM > macro. > > :>I also have an IEFU83 and IEFU84 SMF exits and since SMFWTM is being > used, IEFU83 will > :>be lunched to intercept the previously generated SMF record. > :>Since it is in test, the first thing IEFU83 does is to WTO the SMF type > and subtype it is processing, > :>for debugging purposes. > > :>Now comes the strange part. if the SMF number is between 128 and 205 > (inclusive), the WTO is > :>issued normaly, but if the SMF number is bigger than 205 it seems the > exit is not invoked because > :>no WTO is issued at all. > :>The SMF is generated correctly because I can extract it from SYS1.MANx > datasets. > > :>Here goes a piece of code of IEF83/4 to ilustrate. > > :> USING SMFRCD0,R9 * MAPS SMF RECORD > HEADER > :>DXSOTHR CLI SMF0RTY,128 * SMF SYSTEM RECORD (<128)? > :> BL DXSTYSU * YES, CHECK > TYPE/SUBTYPE/PROD > :> BAS R8,DXMSG <=== TEMP * DISPLAY AND RETURN > > :>DXSTYSU DS 0H > > :>Are there any kind of restriction because it is completely crazy. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > 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 > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- 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: VSEn 6.3 hardware requirements
Hello Radoslav, sorry for the delay, I usually rather follow vse-l https://lists.lehigh.edu/mailman/listinfo/vse-l In any case I was told by a friend (thank you Christian B.!) that there were some VSEn questions, so here I am. The HW req. are exactly the same as with IBM z/VSE 6.2, that is min. z114/z196. Some extra bonus: - 21CS VSEn is committed to support also newer generations of IBM zSystems HW. - 21CS VSEn 6.3 we support not only IBM Storage but also Dell/EMC and Hitachi. - 21CS VSEn 6.3 support direct upgrade via FSU from IBM z/VSE 5.2, 6.1 or 6.2 The is a public presentation from 2022 VM Workshop: http://vmworkshop.org/2022/present/vsenmvng.pdf See slide 11. We recently also presented and a colleague of mine gave a demo showing FSU and new Installation with recording and slides available at the MVMUA: http://www.mvmua.org/2023jan.html Further presentations from the GSE in Germany and UK, I will be happy to follow up with you or anybody else is interested per email: v...@21csw.com All the stack products that are already available are updated here: https://www.21stcenturysoftware.com/vsen/ Looking forward to hear from all the VSE fans :-) Cheers, Gonzalo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JCL // SET SYMBOL indirection
I love symbols. I've been trying to figure out if a level of indirection is possible. Here's an example that both doesn't work and isn't' even syntactically correct, but hopefully will serve to illustrate what I'm trying to do: //SYM1 SET SYM1=VALUE1 //SYM2 SET SYM2=VALUE2 //TARGET SET TARGET=SYM1 //RESULT SET RESULT=&&TARGET (and end up with &RESULT being set to VALUE1 and not SYM1) I know it'll be tempting to ask "why?" but trust me, I have a good reason. Thanks, Rob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL // SET SYMBOL indirection
Not necessarily what you may want, but this works: //SYM1 SET SYM1=VALUE1 //SYM2 SET SYM2=VALUE2 //TARGET SET TARGET=&SYM1 //RESULT SET RESULT=&TARGET (and end up with &RESULT being set to VALUE1 and not SYM1) I know Gil will complain the observed JCL symbol behavior (assigning the value of (a) previously defined symbol(s) to another symbol) is not documented (and it is not), but it definitely works. I use this technique all the time in my application testing JCL. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert Garrett Sent: Tuesday, January 31, 2023 7:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JCL // SET SYMBOL indirection I love symbols. I've been trying to figure out if a level of indirection is possible. Here's an example that both doesn't work and isn't' even syntactically correct, but hopefully will serve to illustrate what I'm trying to do: //SYM1 SET SYM1=VALUE1 //SYM2 SET SYM2=VALUE2 //TARGET SET TARGET=SYM1 //RESULT SET RESULT=&&TARGET (and end up with &RESULT being set to VALUE1 and not SYM1) I know it'll be tempting to ask "why?" but trust me, I have a good reason. Thanks, Rob -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL // SET SYMBOL indirection
Unfortunately, you can not have "nested" symbols...just one and done. Thank you and best regards, Billy Ashton -- Original Message -- From "Robert Garrett" To IBM-MAIN@listserv.ua.edu Date 1/31/2023 7:07:31 PM Subject JCL // SET SYMBOL indirection I love symbols. I've been trying to figure out if a level of indirection is possible. Here's an example that both doesn't work and isn't' even syntactically correct, but hopefully will serve to illustrate what I'm trying to do: //SYM1 SET SYM1=VALUE1 //SYM2 SET SYM2=VALUE2 //TARGET SET TARGET=SYM1 //RESULT SET RESULT=&&TARGET (and end up with &RESULT being set to VALUE1 and not SYM1) I know it'll be tempting to ask "why?" but trust me, I have a good reason. Thanks, Rob -- 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: JCL // SET SYMBOL indirection
I don't know about your question. But herewith a brief side hike: I have always been inclined to experiment with systems, hoping to find sense in what seemed like senseless behavior and looking for shortcuts. (Apparently I was born to be a programmer.) When I was handed a form to fill out, and the form appeared to be a copy of a copy of a too-many-times copy, I wondered why people don't pay more attention to such things. With the advent of half-decent WYSIWYG software I took to creating my own cleaned-up version of the same form, and using that instead, much to the bemusement of the poor clerk who'd never seen that form. If I tried submitting a form with different information than was spelled out (hoping to discover which fields were necessary and which were optional), I might be asked "why do you want to do that?" and told "Don't waste my time playing!" So when I discovered computer programming, I loved it that a computer never asked me "why do you want to do that?" when I experimented with alternate syntax on a command. "Because I want to see what works, of course!", except the machine didn't care. It was wonderful. Therefore when I gradually became a SME myself, subject to people asking how to do something, for a long time I never asked "Why?", because I remember how I disliked it myself. Eventually, though, it dawned on me that in many cases - not all - if I find out what the OP is trying to accomplish, and I point out that the better way of doing it is thus and so, I've actually HELPED. I still feel strongly about letting people try things out to see what works, but if what they really care about is finding a way that works, asking "Why do you want to do that?" often leads to a better solution for them. I'm not asking "Why?" in this case, because I don't care; I don't know the answer anyway. I'm just sayin'. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* There is not really any courage at all in attacking hoary or antiquated things, any more than in offering to fight one's grandmother. The really courageous man is he who defies tyrannies young as the morning and superstitions fresh as the first flowers. The only true free-thinker is he whose intellect is as much free from the future as from the past. -from "What's Wrong with the World" by G K Chesterton */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert Garrett Sent: Tuesday, January 31, 2023 19:08 I love symbols. I've been trying to figure out if a level of indirection is possible. Here's an example that both doesn't work and isn't' even syntactically correct, but hopefully will serve to illustrate what I'm trying to do: //SYM1 SET SYM1=VALUE1 //SYM2 SET SYM2=VALUE2 //TARGET SET TARGET=SYM1 //RESULT SET RESULT=&&TARGET (and end up with &RESULT being set to VALUE1 and not SYM1) I know it'll be tempting to ask "why?" but trust me, I have a good reason. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL // SET SYMBOL indirection
>>//RESULT SET RESULT=&&TARGET (and end up with &RESULT being set to VALUE1 >>and not SYM1) Rob, Try this // EXPORT SYMLIST=* //SYM1 SET SYM1=VALUE1 //SYM2 SET SYM2=VALUE2 //TARGET SET TARGET=SYM1 //RESULT SET RESULT=&TARGET /* //STEP0100 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //LOGDD1 DD SYSOUT=* //SYSUT1 DD *,SYMBOLS=(JCLONLY,LOGDD1) &SYM1 &SYM2 &TARGET &RESULT //SYSUT2 DD SYSOUT=* //SYSINDD DUMMY /* The output of this is VALUE1 VALUE2 SYM1 SYM1 Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL // SET SYMBOL indirection
On Wed, 1 Feb 2023 00:20:26 +, Farley, Peter wrote: >Not necessarily what you may want, but this works: > >//SYM1 SET SYM1=VALUE1 >//SYM2 SET SYM2=VALUE2 > >//TARGET SET TARGET=&SYM1 > >//RESULT SET RESULT=&TARGET (and end up with &RESULT being set to VALUE1 >and not SYM1) > >I know Gil will complain the observed JCL symbol behavior (assigning the value >of (a) previously defined symbol(s) to another symbol) is not documented (and >it is not), but it definitely works. I use this technique all the time in my >application testing JCL. > Yup. I have complained in these pages that every possible construct should either be documented as supported or result in a JCL error. In reply, Peter Relson has sneered at me, saying that I simply don't understand that constructs not documented but allowed should be regarded as for IBM internal use, comparable to undocumented macro parameters, or reserved for future extensions. JCL feels qualitatively different to me; undocumented constructs should at least result in warnings, or there should be a "PRO" option on the job statement, in the absence of which undocumented constructs should be reported as JCL errors. But, like you, I experiment: // SET SYM3='&SYM1 &SYM2' /* No substitution -- it's documented. */ But: // SET Q='&' // SET SYM3=&Q&SYM1 &SYM2&Q /* Substitution performed -- hardly documented. */ But there may be errors reported for using &SYM3 elsewhere, as in PARM=... These behaviors should be documented, but IBM doesn't care. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
