Re: GTTERM assistance (really 3270 VTAM application?)
Michael. Originally, I started on this project to build a PC service provider address space. The address space acquired several 64-bit areas with the IARV64 GETSHARED service, and the service provider would allow problem state address spaces to acquire interest into these 64-bit areas. The 64-bit areas were buffers for monitoring data. I also wanted a 3270 interface for administrative management of the configurations and the monitoring data. Now, this project has morphed into something different. For the register equates, I only use the equates when the equate is related to an active USING statement. With registers 0,1,12 (if not baseless),13,14,and 15 unavailable, it really limits the number of registers for addressing control blocks. I find the register equate methodology very useful and descriptive when managing many DSECTs. I found the solution to my bind problem. All of the examples and most of the manuals referenced the alternate area for bind information. I found one manual that referenced 'Record area' and 'RECLEN'. I change the VTAM INQUIRE macro from AAREA and AAREALN to AREA and AREALEN, and the INQUIRE and OPNDST worked successfully with the bind information returned. Here is the updated source: **-** ** PROGRAM : PORTDSPI ** ** AUTHOR : BRIAN CHAPMAN ** ** WRITTEN ON : 23 AUGUST 2017** ** MODIFIED ON : ** ** ASM OPTIONS : RENT,REUS AMODE=31 RMODE=31 AC=0 ** ** DESCRIPTION : TASK INITIALIZATION ROUTINE ** ** : THIS PROGRAM BUILDS THE INITIAL TASK RELATED ** ** : CONTROL BLOCKS FOR A NEW TASK TO BE DISPATCHED. ** **-** ** * * REGEQU * ** * * COPY PORTKERN * * COPY PORTDMH* * COPY TASKANCH * * COPY SESSVTAM * * COPY SESSSOKT * ** * * EJECT* * IFGRPL AM=VTAM* * EJECT* * ISTUSFBC * * EJECT * * IFGACB AM=VTAM * * EJECT * * IFGEXLST AM=VTAM* * EJECT * * ISTDNIB * * ISTDBIND * ** * *WORKAREA DSECT * *WORKNAME DSCL8 * *SAVEAREA DS18F * *SAVERC DSF* *SAVEANCH DSF* ** * *VTAMRETC DSF* *VTAMFDB2 DSF* ** * *CALLPLST DS0F * *CALLPRM1 DSF* *CALLPRM2 DSF* *CALLPRM3 DSF* *CALLPRM4 DSF* *CALLPRM5 DSF * ** * *WORKLEN EQU *-WORKAREA * ** * *WORKREG EQU R3 * *KERNREG EQU R4 * *ANCHREG EQU R5 * *DMHREG EQU R6 * *VTAMREG EQU R6 * *RPLREG EQU R7* *NIBREG EQU R8 * *ACBREG EQU R9 * *BINDREG EQU R10 * ** * *PORTDSPI CSECT * *PORTDSPI AMODE 31 * *PORTDSPI RMODE ANY * * STM R14,R12,12(R13) SAVE REGISTERS * * LRR12,R15 ESTABLISH BASE * * USING PORTDSPI,R12SET ADDRESSIBILITY* * B START* ** * * DCCL9'PORTDSPI' * * DCCL9'' * * DCCL5'' * *** *STARTDS0H
Re: GTTERM assistance
Normal processing is for the user to enter a logon string and for Unformatted System Services (or the TN3270 equivalent to USS) to convert it to SNA. Shmuel, It should be this scenario. The address space issues the SETLOGON macro with the LOGON parameter which addresses a logon exit routine. I then issue 'LOGON APPLID=A70PORTC' in my emulator, the logon exit routine is invoked, posts the dispatcher ECB, and eventually the PORTDSPI program is invoked to establish the session. I issued a D NET,ID= command to inquire about the status of the opened ACB. Here is the output. *06.53.32 SYSC NET IST097I DISPLAY ACCEPTED* *06.53.32 SYSC NET IST075I NAME = SCA.A70PORTC, TYPE = DYNAMIC APPL* *IST486I STATUS= ACTIV, DESIRED STATE= ACTIV * *IST1447I REGISTRATION TYPE = NETSRVR* *IST1629I MODSRCH = NEVER* *IST977I MDLTAB=***NA*** ASLTAB=***NA*** * *IST861I MODETAB=SCAMODE USSTAB=***NA*** LOGTAB=***NA*** * *IST934I DLOGMOD=***NA*** USS LANGTAB=***NA*** * *IST1632I VPACING = 7 * *IST1938I APPC = NO * *IST597I CAPABILITY-PLU ENABLED ,SLU ENABLED ,SESSION LIMIT NONE * *IST231I APPL MAJOR NODE = MODLCICS * *IST1425I DEFINED USING MODEL A70?* * *IST654I I/O TRACE = OFF, BUFFER TRACE = OFF * *IST1500I STATE TRACE = OFF * *IST271I JOBNAME = TS00JY3N, STEPNAME = ***NA***, DSPNAME = ISTD98B2 * *IST1050I MAXIMUM COMPRESSION LEVEL - INPUT = 0, OUTPUT = 0 * *IST1633I ASRCVLM = 100 * *IST1634I DATA SPACE USAGE: CURRENT = 0 MAXIMUM = 0 * *IST2436I DSMONITR = NO * *IST171I ACTIVE SESSIONS = 00, SESSION REQUESTS = 00 * *IST314I END * Thank you, Brian Chapman On Thu, Nov 10, 2022 at 7:34 AM Seymour J Metz wrote: > Normal processing is for the user to enter a logon string and for > Unformatted System Services (or the TN3270 equivalent to USS) to convert it > to SNA. That process determines a BIND image. If, instead, your application > initiates the session then your application is responsible for providing > the BIND image. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Brian Chapman [bchapma...@gmail.com] > Sent: Wednesday, November 9, 2022 2:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: GTTERM assistance > > Thanks everyone. I went back to my session initialization process and > reviewed my logic for the OPNDST macro. Originally, I did not use the AAREA > or AAREALN parameters on this macro. I added these parameters and set the > NIBNDAR accordingly, but now I'm getting a 084E sense code. > > *09.04.47 JOB21339 +PRT103E VTAM OPNDST request failed for netname > SACTV017. Return = 0004 Sense = 084E.* > > I reviewed the documentation for this sense code. It seems that VTAM is > expecting certain bind fields to be populated, but I'm not sure which > fields. > > Sense code 084E > > Session parameters not valid—PRI: A positive response to an activation > request (for example, BIND) was received and was changed to a negative > response because session parameters that were not valid were carried in the > response. The services manager receiving the response sends a deactivation > request for the corresponding session. This error can occur if NETIDs are > coded incorrectly on any NETWORK statements in CDRM definitions. See z/OS > Communications Server: SNA Resource Definition Reference > < > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.istrdr0%2Ftoc.htmdata=05%7C01%7Csmetz3%40gmu.edu%7C799f7d19d4604778f6fd08dac28d008e%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638036208101949747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pPIC%2B4ngPB8PQcj%2FelTSyfKCH3KdwJXAStf%2FHw988Bo%3Dreserved=0> > for > more information. > Sense code 084E - IBM Documentation > < > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.1.0%3Ftopic%3Dreject-sense-code-084edata=05%7C01%7Csmetz3%40gmu.edu%7C799f7d19d4604778f6fd08dac28d008e%7C9e857255df574c47a0c0054646
Re: GTTERM assistance (really 3270 VTAM application?)
Michael, Are you saying that sense code 084E is only applicable for LU6.2? I receive the same sense code on my emulator when I attempt a logon to the opened ACB. You have 3 R6's?: DMHREG EQU R6 VTAMREG EQU R6 LRR6,R1 LOAD DYNAMIC SESSION LAR8,INITVTAM LOAD INIT MODEL LHI R9,INITVTAL LOAD INIT MODEL LENGTH MVCL R6,R8 COPY INIT MODEL SESSION I'm totally lost on your register usage and which using's are in effect. DMHREG is only in effect for the small section of code before the DROP instruction. I could have used the VTAMREG equate in the MVCL section, but I wanted to be sure that it utilized an even-odd pair. In this case it would have, but I like the flexibility of changing my equate assignments if necessary. Thank you, Brian Chapman On Thu, Nov 10, 2022 at 3:03 AM Michael Stein wrote: > > Sense code 084E - IBM Documentation > > <https://www.ibm.com/docs/en/zos/2.1.0?topic=reject-sense-code-084e> > > That's for LU6.2. What are your terminals, I thought they were 3270s? > > https://www.ibm.com/docs/en/search/3270?scope=SSLTBW_2.4.0=istprg0 > > https://www.ibm.com/docs/en/zos/2.4.0?topic=system-types-3270-terminals > > Types of 3270 terminals > > The following types of 3270 terminals are directly supported by VTAM® > in its domain: > > SNA 3270 terminals: > > Local (PU type 2) > > 3270 terminal attaches to a PU type 2 cluster controller, which > in turn attaches to the VTAM host processor by a System/370 > channel. Example: 3278 Display Station on 3274-1A Control Unit. > > Remote SDLC (PU type 2) > > 3270 terminal attaches to a PU type 2 cluster controller, which > in turn attaches by an SDLC link to a communication controller > containing an NCP, or directly to a processor through a communication > adapter. Example: 3278 Display Station on 3276 Control Unit. > > Remote SDLC (PU type 1) > > 3270 terminal attaches to a PU type 1 cluster controller, which > in turn attaches by an SDLC link to a communication controller > containing NCP, or directly to a processor through a communication > adapter. Examples: 3288 Line Printer on 3271-12 Control Unit or a > 3767 terminal. > > Non-SNA 3270 terminals: > > Local > > 3270 terminal attaches to a non-SNA cluster controller, which in turn > attaches to the VTAM host processor by a System/370 channel. Example: > 3277 Display Station on 3272 Control Unit. A 3270 terminal attached > to a 4331 Display/Printer adapter also presents this appearance. > > Remote BSC > > 3270 terminal attaches to a non-SNA cluster controller, which in turn > attaches by a BSC link to a communication controller containing NCP, > or directly to a processor through a communication adapter. Example: > 3286 Printer on 3271-2 Control Unit. > > In addition, VTAM supports sessions between application programs in the > VTAM host processor and 3270 terminals in another domain in which each > cross-domain terminal provides the appearance of one of the types of > 3270s listed in the preceding discussion. > > You have 3 R6's?: > > DMHREG EQU R6 > VTAMREG EQU R6 > LRR6,R1 LOAD DYNAMIC SESSION > LAR8,INITVTAM LOAD INIT MODEL > LHI R9,INITVTAL LOAD INIT MODEL LENGTH > MVCL R6,R8 COPY INIT MODEL SESSION > > I'm totally lost on your register usage and which using's are in effect. > > -- > 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: GTTERM assistance
I should also add another comment. I was hoping I could just leave the bind area empty and let the SLU (the user's emulator is the SLU in this scenario, right?) populate the bind image with whatever it sends. Thank you, Brian Chapman On Wed, Nov 9, 2022 at 2:59 PM Brian Chapman wrote: > > Thanks everyone. I went back to my session initialization process and > reviewed my logic for the OPNDST macro. Originally, I did not use the AAREA > or AAREALN parameters on this macro. I added these parameters and set the > NIBNDAR accordingly, but now I'm getting a 084E sense code. > > *09.04.47 JOB21339 +PRT103E VTAM OPNDST request failed for netname > SACTV017. Return = 0004 Sense = 084E.* > > I reviewed the documentation for this sense code. It seems that VTAM is > expecting certain bind fields to be populated, but I'm not sure which > fields. > > Sense code 084E > > Session parameters not valid—PRI: A positive response to an activation > request (for example, BIND) was received and was changed to a negative > response because session parameters that were not valid were carried in the > response. The services manager receiving the response sends a deactivation > request for the corresponding session. This error can occur if NETIDs are > coded incorrectly on any NETWORK statements in CDRM definitions. See z/OS > Communications Server: SNA Resource Definition Reference > <https://www.ibm.com/docs/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.istrdr0/toc.htm> > for > more information. > Sense code 084E - IBM Documentation > <https://www.ibm.com/docs/en/zos/2.1.0?topic=reject-sense-code-084e> > > I also reviewed Table 2 on this page, BIND image and response - IBM > Documentation > <https://www.ibm.com/docs/en/zos/2.4.0?topic=sessions-bind-image-response>, > and most of the fields that I thought to update are listed as 'VTAM > ignores or overrides application program's setting.' > > Here is the program that's establishing the session. It acquires the user > control blocks necessary for terminal based tasks, and then executes the > OPNDST macro. Again, any assistance would be greatly appreciated. > > **-----** > ** PROGRAM : PORTDSPI ** > ** AUTHOR : BRIAN CHAPMAN ** > ** WRITTEN ON : 23 AUGUST 2017** > ** MODIFIED ON : ** > ** ASM OPTIONS : RENT,REUS AMODE=31 RMODE=31 AC=0 ** > ** DESCRIPTION : TASK INITIALIZATION ROUTINE ** > ** : THIS PROGRAM BUILDS THE INITIAL TASK RELATED ** > ** : CONTROL BLOCKS FOR A NEW TASK TO BE DISPATCHED. ** > **-** > ** * > * REGEQU * > ** * > * COPY PORTKERN * > * COPY PORTDMH* > * COPY TASKANCH * > * COPY SESSVTAM * > * COPY SESSSOKT * > ** * > * EJECT * > * IFGRPL AM=VTAM * > * EJECT* > * ISTUSFBC * > * EJECT * > * IFGACB AM=VTAM * > * EJECT * > * IFGEXLST AM=VTAM* > * EJECT * > * ISTDNIB* > * ISTDBIND * > ** * > *WORKAREA DSECT * > *WORKNAME DSCL8 * > *SAVEAREA DS18F * > *SAVERC DSF * > *SAVEANCH DSF* > ** * > *VTAMRETC DSF * > *** > *CALLPLST DS0F* > *CALLPRM1 DSF * > *CALLPRM2 DSF * > *CALLPRM3 DSF * > *CALLPRM4 DSF * > *CALLPRM5 DSF * > ** * > *WORKLEN EQU *-WORKAREA* > ** * > *WORKREG EQU R3 * > *KERNREG EQU R4 * > *ANCHREG EQU R5* > *DMHREG EQU R6 * > *VTAMREG EQU R6
Re: GTTERM assistance
Thanks everyone. I went back to my session initialization process and reviewed my logic for the OPNDST macro. Originally, I did not use the AAREA or AAREALN parameters on this macro. I added these parameters and set the NIBNDAR accordingly, but now I'm getting a 084E sense code. *09.04.47 JOB21339 +PRT103E VTAM OPNDST request failed for netname SACTV017. Return = 0004 Sense = 084E.* I reviewed the documentation for this sense code. It seems that VTAM is expecting certain bind fields to be populated, but I'm not sure which fields. Sense code 084E Session parameters not valid—PRI: A positive response to an activation request (for example, BIND) was received and was changed to a negative response because session parameters that were not valid were carried in the response. The services manager receiving the response sends a deactivation request for the corresponding session. This error can occur if NETIDs are coded incorrectly on any NETWORK statements in CDRM definitions. See z/OS Communications Server: SNA Resource Definition Reference <https://www.ibm.com/docs/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.istrdr0/toc.htm> for more information. Sense code 084E - IBM Documentation <https://www.ibm.com/docs/en/zos/2.1.0?topic=reject-sense-code-084e> I also reviewed Table 2 on this page, BIND image and response - IBM Documentation <https://www.ibm.com/docs/en/zos/2.4.0?topic=sessions-bind-image-response>, and most of the fields that I thought to update are listed as 'VTAM ignores or overrides application program's setting.' Here is the program that's establishing the session. It acquires the user control blocks necessary for terminal based tasks, and then executes the OPNDST macro. Again, any assistance would be greatly appreciated. **-** ** PROGRAM : PORTDSPI ** ** AUTHOR : BRIAN CHAPMAN ** ** WRITTEN ON : 23 AUGUST 2017** ** MODIFIED ON : ** ** ASM OPTIONS : RENT,REUS AMODE=31 RMODE=31 AC=0 ** ** DESCRIPTION : TASK INITIALIZATION ROUTINE ** ** : THIS PROGRAM BUILDS THE INITIAL TASK RELATED ** ** : CONTROL BLOCKS FOR A NEW TASK TO BE DISPATCHED. ** **-** ** * * REGEQU * ** * * COPY PORTKERN * * COPY PORTDMH* * COPY TASKANCH * * COPY SESSVTAM * * COPY SESSSOKT * ** * * EJECT * * IFGRPL AM=VTAM * * EJECT* * ISTUSFBC * * EJECT * * IFGACB AM=VTAM * * EJECT * * IFGEXLST AM=VTAM* * EJECT * * ISTDNIB* * ISTDBIND * ** * *WORKAREA DSECT * *WORKNAME DSCL8 * *SAVEAREA DS18F * *SAVERC DSF * *SAVEANCH DSF* ** * *VTAMRETC DSF * *** *CALLPLST DS0F* *CALLPRM1 DSF * *CALLPRM2 DSF * *CALLPRM3 DSF * *CALLPRM4 DSF * *CALLPRM5 DSF * ** * *WORKLEN EQU *-WORKAREA* ** * *WORKREG EQU R3 * *KERNREG EQU R4 * *ANCHREG EQU R5* *DMHREG EQU R6 * *VTAMREG EQU R6 * *RPLREG EQU R7 * *NIBREG EQU R8 * *ACBREG EQU R9 * ** * *PORTDSPI CSECT * *PORTDSPI AMODE 31 * *PORTDSPI RMODE ANY * * STM R14,R12,12(R13) SAVE REGISTERS * * LRR12,R15 ESTABLISH BASE * * USING PORTDSPI,R12SET ADDRESSIBILITY * * B START * ** * *
Re: GTTERM assistance
Michael, I really appreciate the critiques. I agree that some of my comments are misleading and need to be updated. I like the suggestion for MVCL. I was not aware of the potential hazards with register 2. Using register 2 as a save register when acquiring a DSA is very common in all of my code. I'll be more judicious with my usage of this register. For the register equates, I've found myself reassigning register usages often and having equates like "SESSREG EQU R5" have made that really easy in the past. If I find that register 6 aligns more easily with a particular instruction (MVCL for example), then updating the equate for SESSREG is much easier than performing CHANGE ALL commands and inadvertently changing a field name, literal, or some other string. Thank you, Brian Chapman On Tue, Nov 1, 2022 at 7:28 PM Michael Stein wrote: > > Any assistance would be greatly appreciated. > > > > I am working on a SNA interface for a batch framework. This is mostly > just > > a massive learning exercise that will likely never be utilized, but I > have > > learned SO much while working on this project (currently 6 years in the > > making). > > I'm confused about what this is part of. Is this a TSO program > or something else (saying SNA? VTAM APPL?). > > I ask that because as far as I know GTTERM is TSO only. But > you got return code 0 so perhaps the GTTERM is being issued > from TSO. > > > The address space accepts terminals with MOD2 terminals and everything > > "Terminals" plural. A TSO session with more than one? > > > I check register 15 after the SVC, and it is zero. But the SVC parameter > > values are still zero. > > When using MF=L and MF=E macro forms, usually it's necessary to copy > an MF=L list into the DSECT area before using the MF=E form... > > This is not true for all macros, but perhaps for GTTERM. > > So somewhere in the source should be a GTTERM MF=L and then it should > be copied (MVC) into GTTLIST in the DSECT before issuing the GTTERM > MF=(E,GTTLIST). I'd suggest looking at the full expansion of the GTTERM > (both MF=L and MF=E) to see if this is needed. > > Other points: > > > WORKREG EQU R3 > > SESSREG EQU R5 > > I've only used 16 registers R0->R15. You can do what you want but I'd > be very careful that additional register equates didn't result in some > duplicate register usage. I saw some IBM source which had: > > R15 EQU R9 > > I'd prefer better comments, or when trivial, no comment. As an > example: > > > LRR2,R1 SAVE REGISTER 2 > > This appears backwards, saving R1 in R2. Also R2 is a problematic > register as some hardware instructions alter it without it being specified > (TRT translate and test at least). I'd be careful when I used it and > treat it as a bit less temporary than R0, R1, R14, R15. > > More comments on comments (& register usage): > > > LRR6,WORKREG LOAD REGISTER > > LAR8,0SET DUMMY FROM ADDRESS > > XRR9,R9 SET PADDING TO LOW VALUES > > MVCL R6,R8 INITIALIZE AREA > > I'd suggest something like: > >LRR6,WORKREG @ workarea to clear, len in R7 >SRR15,R15 >MVCL R6,R14 > > The contents of R14 don't matter for the MVCL as the length in R15 is zero. > > -- > 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: GTTERM assistance
All, Thank you for the feedback. I've been following the excellent write up by Greg Price (3270 Extended Data Stream (prycroft6.com.au) <https://www.prycroft6.com.au/misc/3270eds.html>) for understanding 3270 datasteams. This write up and Tommy Sprinkle's (3270 Data Stream Programming (tommysprinkle.com) <http://www.tommysprinkle.com/mvs/P3270/start.htm>) are a gold mine. I was following his coding example for checking if the terminal accepts a Query, but I mistakenly overlooked the fact that this is only for TSO. I planned to add the GTTERM early in the process of establishing the VTAM terminal to determine if Read Partition - Query is acceptable. For a VTAM application, is it safe to assume that all connecting terminals accept Read Partition - Query? 1. Check for a 3270 terminal: GTSIZE Determine terminal screen dimensions LTR R0,R0 3270 screen? BZLINEMODE No, cannot do full screen 3270 I/O 2. Check if Read Partition (Query) is allowed: GTTERM PRMSZE=PRIMSIZE,ALTSZE=ALTSIZE,ATTRIB=TERMATTR LTR R15,R15Did GTTERM work? BZNOQUERYNo, VTAM must be pre-ACF/VTAM TMTERMATTR+3,X'01' Query allowed? BNO NOQUERYNo ... ... PRIMSIZE DCAL1(0,0) Primary screen size ALTSIZE DCAL1(0,0) Alternate screen size TERMATTR DCF'0' Terminal attributes 3. Activate VTAM full screen mode without input data stream editing: STFSMODE ON,NOEDIT=YES 4. Issue Read Partition (Query): LAR1,RESETAID LAR0,L'RESETAID ICM R1,8,=X'0B'Load TPUT FULLSCR,WAIT,HOLD flags TPUT (1),(0),R Reset the Attention IDentifier TPG QUERY,L'QUERY,NOEDIT,WAIT Issue Query ... ... RESETAID DCX'27F5C3' Escape, Erase/Write, WCC for resetting AID and MDTs QUERYDCX'F3000501FF02'Read Partition structured field Thank you, Brian Chapman On Wed, Nov 2, 2022 at 4:36 AM Seymour J Metz wrote: > Yes, GTTERM is TSO only. For a direct VTAM application, you need to send a > Read Partition - Query and parse the query reply. > > AFAIK, GTTERM is one of the macros where you don't need to initialize the > parameter list. > > > -- > 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: Tuesday, November 1, 2022 7:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: GTTERM assistance > > > Any assistance would be greatly appreciated. > > > > I am working on a SNA interface for a batch framework. This is mostly > just > > a massive learning exercise that will likely never be utilized, but I > have > > learned SO much while working on this project (currently 6 years in the > > making). > > I'm confused about what this is part of. Is this a TSO program > or something else (saying SNA? VTAM APPL?). > > I ask that because as far as I know GTTERM is TSO only. But > you got return code 0 so perhaps the GTTERM is being issued > from TSO. > > > The address space accepts terminals with MOD2 terminals and everything > > "Terminals" plural. A TSO session with more than one? > > > I check register 15 after the SVC, and it is zero. But the SVC parameter > > values are still zero. > > When using MF=L and MF=E macro forms, usually it's necessary to copy > an MF=L list into the DSECT area before using the MF=E form... > > This is not true for all macros, but perhaps for GTTERM. > > So somewhere in the source should be a GTTERM MF=L and then it should > be copied (MVC) into GTTLIST in the DSECT before issuing the GTTERM > MF=(E,GTTLIST). I'd suggest looking at the full expansion of the GTTERM > (both MF=L and MF=E) to see if this is needed. > > Other points: > > > WORKREG EQU R3 > > SESSREG EQU R5 > > I've only used 16 registers R0->R15. You can do what you want but I'd > be very careful that additional register equates didn't result in some > duplicate register usage. I saw some IBM source which had: > > R15 EQU R9 > > I'd prefer better comments, or when trivial, no comment. As an > example: > > > LRR2,R1 SAVE REGISTER 2 > > This appears backwards, saving R1 in R2. Also R2 is a problematic > register as some hardware instructions alter it without it being specified > (TRT translate and test at least). I'd be careful when I used it and > treat it as a bit less temporary than R0, R1, R14, R15. > > More comments on comments
Re: GTTERM assistance
Shmuel, All I see is that your save area code is bad Thanks. I'm not sure how that 64 bit save area code got stuck in there. What's in SESSBLK? SESSBLK is just a user control block with the 'session' variables. The values for SESSPRI and SESSALT and SESSATTR are still zero after the SVC call. I would probably have written something like GTTLIST GTTERM PRMSZE=SESSPRI,ALTSZE=SESSALT,ATTRIB=SESSATTR, * MF=(E,GTTLIST) for documentation, but AFAIK that wouldn't affect the length. I'm not sure I understand. I get an assembly error with "Previously defined symbol' when I re-use the GTTLIST label. Thank you, Brian Chapman On Tue, Nov 1, 2022 at 3:42 PM Seymour J Metz wrote: > All I see is that your save area code is bad, but that shouldn't affect > the returned values from GTTERM. What's in SESSBLK? > > I would probably have written something like > > GTTLIST GTTERM PRMSZE=SESSPRI,ALTSZE=SESSALT,ATTRIB=SESSATTR, * >MF=(E,GTTLIST) > > for documentation, but AFAIK that wouldn't affect the length. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Brian Chapman [bchapma...@gmail.com] > Sent: Tuesday, November 1, 2022 2:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: GTTERM assistance > > Hello all, > > Any assistance would be greatly appreciated. > > I am working on a SNA interface for a batch framework. This is mostly just > a massive learning exercise that will likely never be utilized, but I have > learned SO much while working on this project (currently 6 years in the > making). > > The address space accepts terminals with MOD2 terminals and everything > displays great. However, I would like to support larger terminal sizes. My > first hurdle is GTTERM. I understand that my program should be in RMODE24 > and AMODE24. The program is assembled with AMODE 31, but performs a SAM24 > and SAM31 before and after the SVC call. The dynamic storage area for the > program is also acquired below the line. > > I check register 15 after the SVC, and it is zero. But the SVC parameter > values are still zero. > > Here is my source: > > REGEQU > COPY SESSBLK > * > WORKAREA DSECT > WORKNAME DSCL8 > SAVEAREA DS18F > SAVERC DSF > SAVEPARM DSF > * > GTTLIST GTTERM MF=L > * > WORKLEN EQU *-WORKAREA > * > WORKREG EQU R3 > SESSREG EQU R5 > * > PORTTC04 CSECT > PORTTC04 AMODE 31 > PORTTC04 RMODE 24 > STM R14,R12,12(R13) SAVE REGISTERS > LRR12,R15 ESTABLISH BASE > USING PORTTC04,R12* > B START > * > DCCL9'PORTTC04' > DCCL9'' > DCCL5'' > * > STARTDS0H > LRR2,R1 SAVE REGISTER 2 > LHI R7,WORKLEN LOAD WORK AREA LENGTH > GETMAIN RU,LV=(R7),LOC=BELOW > LRWORKREG,R1 * > USING WORKAREA,WORKREGSET ADDRESSIBILITY > * > LRR6,WORKREG LOAD REGISTER > LAR8,0SET DUMMY FROM ADDRESS > XRR9,R9 SET PADDING TO LOW VALUES > MVCL R6,R8 INITIALIZE AREA > * > STR13,SAVEAREA+4 CHAIN CALLER'S SAVEAREA ADDRESS > LAR13,SAVEAREA > STR13,SAVEAREA+8 SAVE CURRENT SAVEAREA ADDRESS > MVC SAVEAREA(4),=CL4'F4SA' > MVC WORKNAME(8),=CL8'PORTTC04' > * > GETLINK DS0H > LRR1,R2 RESTORE REGISTER 2 > STR1,SAVEPARM > LTSESSREG,4(R1) GET ADDRESS OF SESSBLK > BZBADLINK NO LINKAGE PASSED > USING SESSBLK,SESSREG SET ADDRESSIBILITY > * > GETTERM DS0H > SAM24 > * > GTTERM PRMSZE=SESSPRI,ALTSZE=SESSALT,ATTRIB=SESSATTR, * >MF=(E,GTTLIST) > * > ABEND 91,DUMP > SAM31 > * > LTR R15,R15 > BNZ BADRC > * > STR15,SESSATTR+4 > * > B RETURN > * > BADRCDS0H > WTO 'PORTTC04 BAD GTTERM RC' > MVHI SAVERC,16 SET BAD RETURN CODE > ABEND 98,DUMP > * > BADLINK DS0H > WTO 'PORTTC04 INVALID LINKAGE PARAMETERS' > MVHI SAVERC,16 SET BAD RETURN CODE > ABEND 99,DUMP > * > RETURN DS0H > L R13,SAVEAREA+4
GTTERM assistance
*.. &* 0002CF68 000F68 ** 0002CF78 000F78 ** 0002CF88 000F88 ** 0002CF98 000F98 000943C8 *.. H* 0002CFA8 000FA8 0002CBFC 0002CBFE *.. .. * 0002CFB8 000FB8 8002CC00 * .ö.* 0002CFC8 000FC8 ** 0002CFD8 000FD8 ** 0002CFE8 000FE8 ** Address Offset from _0002C000Origin STORAGE 0001 0002CBFC 000BFC ** Address Offset from _0002C000Origin STORAGE 0001 0002CBFE 000BFE ** Address Offset from _0002C000Origin STORAGE 0001 0002CC00 000C00 ** Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unix System Services migration
Carmen/ Shmuel, Thank you. I will review these reference manuals. Thank you, Brian Chapman On Thu, Sep 29, 2022 at 9:19 AM Carmen Vitullo wrote: > that's a better reference - I have a PDF saved on my work PC somewhere, > but this looks about the same > > Carmen > > On 9/29/2022 8:05 AM, Seymour J Metz wrote: > > See "Chapter 7. Sharing file systems in a sysplex" in z/OS 2.5 UNIX > System Services Planning, GA32-0884-50. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Brian Chapman [bchapma...@gmail.com] > > Sent: Thursday, September 29, 2022 8:54 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Unix System Services migration > > > > How are most shops handling USS management and migration? > > > > For many years, there has been a strong sentiment in my shop against > > utilizing USS (security and scalability were always cited as the primary > > reasons) and we were only allowed to utilize USS with IBM and ISV > software > > installs. Things are changing and now there is a strong push to change > our > > culture around USS. However, we are greatly behind with the times and > > inexperienced with best management practices regarding USS migrations. > > > > I'm sure our shop isn't the only site with a similar configuration, but > we > > have multiple systems for development lifecycles (alpha testing on SYSA > and > > SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate > > dataset mounts for each system, this makes sharing common resources > across > > the same lifecycle environment impossible; unless it is read-only (but > how > > do you update the file system without an outage?). Is there some sort of > > management practice that we're missing to achieve the ability to leverage > > common resources in USS? > > > > Also, how do you handle migration? Our shop uses CA Endevor. Do you > employ > > your change management software with USS migrations? If so, how do you > copy > > directories/folders without outages? For directories/files that can > easily > > be built with jobs, do you re-run these jobs on each system, or copy > these > > elements? > > > > > > > > > > Thank you, > > > > Brian Chapman > > > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Unix System Services migration
How are most shops handling USS management and migration? For many years, there has been a strong sentiment in my shop against utilizing USS (security and scalability were always cited as the primary reasons) and we were only allowed to utilize USS with IBM and ISV software installs. Things are changing and now there is a strong push to change our culture around USS. However, we are greatly behind with the times and inexperienced with best management practices regarding USS migrations. I'm sure our shop isn't the only site with a similar configuration, but we have multiple systems for development lifecycles (alpha testing on SYSA and SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate dataset mounts for each system, this makes sharing common resources across the same lifecycle environment impossible; unless it is read-only (but how do you update the file system without an outage?). Is there some sort of management practice that we're missing to achieve the ability to leverage common resources in USS? Also, how do you handle migration? Our shop uses CA Endevor. Do you employ your change management software with USS migrations? If so, how do you copy directories/folders without outages? For directories/files that can easily be built with jobs, do you re-run these jobs on each system, or copy these elements? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX - Interpret or Value - Which is better?
Years ago I used INTERPRET often, and I too switched to VALUE. There's
still one use case that I still use INTERPRET, and that's for 'passing'
many variables (most of which are stem) between programs.
This program reads an input dataset that contains all of the variable names
that should be passed. It then uses INTERPRET to append the variable names
and values to the PARMS variable. It then performs the CALL. The calling
subprogram performs an INTERPRET on ARG(1). Once the subprogram returns, it
uses INTERPRET to receive the returned variables and values.
*CALL DRAW_PARMS*
*PARMS = PARMS"OBJPOS='"OBJPOS"';OBJLEN='"OBJLEN"';OBJINTS='"OBJINTS"';",*
* "OBJHILT='"OBJHILT"';OBJCOLR='"OBJCOLR"';OBJVAL='"OBJVAL"'"*
*CALL SCRNTXAT PARMS*
*IF RESULT = 'RESULT' THEN *
* NOP *
*ELSE *
* CALL PARSE_PARMS RESULT *
*DRAW_PARMS: *
* PARMS = '' *
* ADDRESS TSO *
* "ALLOC DATASET('"SYSPROC"("SCRNGLBL")') FILE(PARM) SHR" *
* 'EXECIO * DISKR PARM (FINIS STEM PARMS.'*
* 'FREE FILE(PARM)'*
* DO I = 1 TO PARMS.0 *
*PARM = SPACE(SUBSTR(PARMS.I,1,12))*
*IF PARM > '' THEN DO *
* IF POS('.',PARM) = LENGTH(PARM) THEN DO *
*INTERPRET "STEM_MAX = "PARM'0'*
*DO J = 0 TO STEM_MAX *
* INTERPRET "PARMS = PARMS||PARM||J'='''"PARM||J"''';'"*
*END *
* END *
* ELSE*
*INTERPRET "PARMS = PARMS||PARM'='''"PARM"''';'" *
*END *
* END*
* DO I = 1 TO OBJ_CNT *
*PARSE VAR OBJ_NDX.I DRAW_ROW_NUM '.' DRAW_FLD_CNT *
*INTERPRET "PARMS = PARMS||"OBJ_NDX"'.'I'='||'''"OBJ_NDX.I"'''||';'"*
*DO J = 1 TO ATTR_CNT *
* PARM_VAL = OBJ.DRAW_ROW_NUM.DRAW_FLD_CNT.J *
* IF POS("'",PARM_VAL) > 0 THEN DO *
*CALL CHANGE_STR PARM_VAL,"'","''" *
*PARM_VAL = STRING *
* END *
* INTERPRET "PARMS = PARMS||"OBJ.DRAW_ROW_NUM.DRAW_FLD_CNT||, *
*"'.'J'='''PARM_VAL''';'" *
*END*
* END *
*RETURN*
*PARSE_PARMS:*
* PARMS = ARG(1)*
* INTERPRET PARMS*
*RETURN *
Thank you,
Brian Chapman
On Mon, Sep 13, 2021 at 10:19 AM Bob Bridges wrote:
> I use INTERPRET here and there, but pretty rarely. About the only program
> with it that I use all the time is something I call "EV" (for "evaluate),
> that acts as a sort of ad-hoc calculator:
>
> parse arg v1
> interpret 'v2='v1
> say v1'='v2
>
> Thus I can say on any ISPF command line "tso ev 228/15" and learn how many
> cylinders that dataset is. Or "tso ev mvsvar('SYSNAME')" to look at the
> local node name. Or "tso ev xxx(45)" to test a new external REXX function.
>
> But I keep thinking about the possibilities for malice in any tool I write
> for public use, and worry about it. I can't think of any examples, because
> as Itschak points out below, it's always going to run under the
> perpetrator's own ID, so INTERPRET isn't giving him any capabilities he
> doesn't already have. Can anyone point me to an example of how this would
> become a Bad Thing? I'm really curious.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
Re: Can I use a REXX PLIST when calling a COBOL program?
Cameron, If you add the data areas to the PROCEDURE DIVISION USING statement, then COBOL will set the linkage accordingly. Thank you, Brian Chapman On Mon, Mar 22, 2021 at 9:13 AM Cameron Conacher wrote: > Hello everyone, > I have been busy playing with an old support pac from IBM that enables REXX > to call an Assembler routine that in turn invokes EXCI. > Not terribly important, but I thought the PLIST interface between REXX and > Assembler was pretty slick. I had not seen it before. (and the support pac > was from 1996!) > > It got me to wondering if I could do something similar with REXX calling a > COBOL routine. > Can I pass a PLIST from REXX to a COBOL program? > > If I can pass the PLIST, do I need to parse the pointer list myself, or can > I just list out the linkage section items in the order I expect them. > > Thanks for any thoughts, > > ...Cameron > > -- > 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: This Call-Assembler-inside-COBOL technique works, but is it risky to use?
Frank, Do you have a source? https://www.ibm.com/support/knowledgecenter/SS6SG3_6.1.0/pg/tasks/tpbeg04d.html A constant is a data item that has only one value. COBOL does not define a construct for constants. However, you can define a data item with an initial value by coding a VALUE clause in the data description (instead of coding an INITIALIZE statement). On Wed, Mar 17, 2021, 5:48 PM Frank Swarbrick wrote: > The current COBOL standard supports constants. Not a CONSTANTS-SECTION > but something like: > 01 my-constant IS CONSTANT VALUE "This is a constant string". > > I may have the syntax not quite correct, but don't feel like looking it up. > > IBM has not yet implemented this support in Enterprise COBOL. > > > From: IBM Mainframe Discussion List on behalf > of Farley, Peter x23353 <031df298a9da-dmarc-requ...@listserv.ua.edu> > Sent: Wednesday, March 17, 2021 2:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it > risky to use? > > Yeah, I've seen that one too, but that could also happen to any > dynamically called subroutine loaded in non-store-protected memory if the > table index overrun is big enough (BTDTGTTS and the scars). > > I wouldn't contemplate embedding such "clever" code in a "normal" > application program for the very reason you state, but instead I would put > it in its own separately compiled subroutine intended to be dynamically > called. Then if they overrun a table limit by a REALLY big amount they > will have overwritten far more than just my "clever" routine. > > Having a CONSTANTS SECTION in addition to WORKING-STORAGE and > LOCAL-STORAGE sections would be very nice indeed, and better still if the > CONSANTS section used a store-protected storage pool, but we don’t have > that, as you say. > > Of course, just writing the actual assembler code and making that source > program yet another separately compiled subroutine is always an option > too. It just feels like overkill for a four-instruction subroutine (not > counting CSECT, END, AMODE, and RMODE). > > Replacing "clever" with a "builtin function" like XLC has would be my > preferred solution, but we don’t have that to hand yet either. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Brian Chapman > Sent: Wednesday, March 17, 2021 3:54 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it > risky to use? > > It would be nice if COBOL had constant constructs. Knowing my shop's COBOL > developers, I could easily see one of them placing a table above this, > programmatically ignoring the COBOL OCCURS statement, and overrunning the > table and into your VALUE statements. > > Thank you, > > Brian Chapman > > > On Wed, Mar 17, 2021 at 2:12 PM Gibney, Dave wrote: > > > The code looks fine, even if invoked in 64 bit mode. I'd worry a bit > > more about the cache hit, the STCK is likely storing into the same cache > line. > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Farley, Peter x23353 > > > Sent: Wednesday, March 17, 2021 11:06 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: This Call-Assembler-inside-COBOL technique works, but > > > is it > > risky > > > to use? > > > > > > Yes, making it a simple callable assembler routine is the safest > > > option, > > but > > > introduces yet another assembler routine into the production source > > > pool when there are fewer and fewer assembler-knowledgeable > > > programmers left. > > > > > > If COBOL supported the "hardware builtin" functions provided with > > > XLC it would be totally safe. > > > > > > As I said in a prior reply, I worry most about the structure of the > > > PROCEDURE-POINTER possibly changing for 64-bit mode, which an > > > assembler subroutine certainly avoids. > > > > > > Peter > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Matt Hogstrom > > > Sent: Wednesday, March 17, 2021 1:29 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: This Call-Assembler-inside-COBOL technique works, but > > > is it > > risky > > > to use? > > > > > > I recall doing something like this about 30 years ago which I know > > > would break one day. I wanted to pr
Re: HLASM question about SQLITE3
** ASMA224E No control section defined, external reference with GOFF option ignored - ###0021 Does the error say 021 or 0022? If it's 0022 then it looks like you're missing a CSECT. Thank you, Brian Chapman On Wed, Mar 17, 2021 at 3:49 PM Dave Jones wrote: > Hi, all. > I am now working with John McKown's port of SQLITE3 to z/OS Unix Systems > services. However when I attempt to compile the SQLITE3A member with HLASM > 1.6, I get errors that state: > 581 **OLDMKFUNC > sqlite3_backup_ > 582 MKFUNC > sqlite3_backup_ > 010C 583+ DS 0F > > 010C 0134584+ DC > A(__$0022) > 0110 0018585+ DC A(24) > > 0114 586+ DC > V(###0022) > ** ASMA224E No control section defined, external reference with GOFF > option ignored - ###0021 > > Does anyone know how to correct this error? > Many thanks. > DJ > > -- > 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: This Call-Assembler-inside-COBOL technique works, but is it risky to use?
It would be nice if COBOL had constant constructs. Knowing my shop's COBOL developers, I could easily see one of them placing a table above this, programmatically ignoring the COBOL OCCURS statement, and overrunning the table and into your VALUE statements. Thank you, Brian Chapman On Wed, Mar 17, 2021 at 2:12 PM Gibney, Dave wrote: > The code looks fine, even if invoked in 64 bit mode. I'd worry a bit more > about the cache hit, the STCK is likely storing into the same cache line. > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Farley, Peter x23353 > > Sent: Wednesday, March 17, 2021 11:06 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it > risky > > to use? > > > > Yes, making it a simple callable assembler routine is the safest option, > but > > introduces yet another assembler routine into the production source pool > > when there are fewer and fewer assembler-knowledgeable programmers > > left. > > > > If COBOL supported the "hardware builtin" functions provided with XLC it > > would be totally safe. > > > > As I said in a prior reply, I worry most about the structure of the > > PROCEDURE-POINTER possibly changing for 64-bit mode, which an assembler > > subroutine certainly avoids. > > > > Peter > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Matt Hogstrom > > Sent: Wednesday, March 17, 2021 1:29 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it > risky > > to use? > > > > I recall doing something like this about 30 years ago which I know would > > break one day. I wanted to process VB ISAM but that wasn’t supported so > I > > figured out a way to search backwards from WS with negative indexes > until I > > found the DCB for the file and “moved a byte” with the right bit on for > V. > > > > I would expect your hack to work for many years, although, the next guy > to > > try and maintain the code might not understand it. I’d make it callable > > module. I mean, who doesn’t need a good STCK once in a while? > > > > Nice. > > > > Matt Hogstrom > > m...@hogstrom.org > > PGP Key: 0x90ECB270 > > > > > On Mar 17, 2021, at 11:50 AM, Farley, Peter x23353 <031df298a9da- > > dmarc-requ...@listserv.ua.edu> wrote: > > > > > > I discovered that one can code and call extremely simple assembler code > > from completely within a COBOL source program, but it is a two-step > process > > which I will describe below. > > > > > > My question is whether using a technique like this is "risky" in the > sense > > that it may someday, under a future incarnation of the compiler, stop > > working? > > > > > > The technique: > > > > > > Code a simple assembler program like the following and browse the > > resulting listing that shows the generated object code: > > > > > > COBSTCKE CSECT , > > > L 15,0(,1) GET ARGUMENT ADDRESS > > > STCKE 0(15) STCKE INTO ARGUMENT AREA > > > XR15,15 SET RETURN CODE = 0 > > > BR14RETURN TO CALLER > > > > > > Then copy the generated object code into a COBOL source program as > > follows: > > > > > > ID DIVISION. > > > PROGRAM-ID. COBSTCKE. > > > ENVIRONMENT DIVISION. > > > DATA DIVISION. > > > WORKING-STORAGE SECTION. > > > 01 WS-TOD-VALUE PIC X(16). > > > > > > 01 WS-GETTOD-PROGRAM. > > > * GET ARGUMENT ADDRESS L 15,0(,1) > > > 05 FILLER PIC X(04) VALUE X'58F01000'. > > > * STCKE INTO ARGUMENT AREA STCKE 0(15) > > > 05 FILLER PIC X(04) VALUE X'B278F000'. > > > * SET RETURN-CODE = 0 XR 15,15 > > > 05 FILLER PIC X(02) VALUE X'17FF'. > > > * RETURN TO CALLER BR 14 > > > 05 FILLER PIC X(02) VALUE X'07FE'. > > > > > > 01 WS-GETTOD-PTR. > > > 05 GETTOD-ADDRPROCEDURE-POINTER VALUE NULL. > > > 05 FILLER REDEFINES GETTOD-ADDR. > > > 10 GETTOD-ADDR1 POINTER. > > > 10
Re: Contents of TOD Programmable Field under z/OS?
I may need wrong, but I seem to remember reading that the 12 bit lower order value had some relation to the processor ID. This ensured the STCK value would be unique across the sysplex. On Wed, Mar 17, 2021, 1:55 PM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > But is it documented anywhere? PoOP is silent on the value of the field. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Salva Carrasco > Sent: Wednesday, March 17, 2021 12:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Contents of TOD Programmable Field under z/OS? > > Afaik unique to the LPAR & Sysplex. > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use?
Peter, This is interesting, but how is this better than just link-editing the assembler program into the COBOL program? Thank you, Brian Chapman On Wed, Mar 17, 2021 at 11:50 AM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > I discovered that one can code and call extremely simple assembler code > from completely within a COBOL source program, but it is a two-step process > which I will describe below. > > My question is whether using a technique like this is "risky" in the sense > that it may someday, under a future incarnation of the compiler, stop > working? > > The technique: > > Code a simple assembler program like the following and browse the > resulting listing that shows the generated object code: > > COBSTCKE CSECT , > L 15,0(,1) GET ARGUMENT ADDRESS > STCKE 0(15) STCKE INTO ARGUMENT AREA > XR15,15 SET RETURN CODE = 0 > BR14RETURN TO CALLER > > Then copy the generated object code into a COBOL source program as follows: > >ID DIVISION. >PROGRAM-ID. COBSTCKE. >ENVIRONMENT DIVISION. >DATA DIVISION. >WORKING-STORAGE SECTION. >01 WS-TOD-VALUE PIC X(16). > >01 WS-GETTOD-PROGRAM. > * GET ARGUMENT ADDRESS L 15,0(,1) >05 FILLER PIC X(04) VALUE X'58F01000'. > * STCKE INTO ARGUMENT AREA STCKE 0(15) >05 FILLER PIC X(04) VALUE X'B278F000'. > * SET RETURN-CODE = 0 XR 15,15 >05 FILLER PIC X(02) VALUE X'17FF'. > * RETURN TO CALLER BR 14 >05 FILLER PIC X(02) VALUE X'07FE'. > >01 WS-GETTOD-PTR. >05 GETTOD-ADDRPROCEDURE-POINTER VALUE NULL. >05 FILLER REDEFINES GETTOD-ADDR. >10 GETTOD-ADDR1 POINTER. >10 GETTOD-ADDR2 POINTER. > >PROCEDURE DIVISION. > >SET GETTOD-ADDR1 TO ADDRESS OF WS-GETTOD-PROGRAM. >CALL GETTOD-ADDR USING WS-TOD-VALUE. >DISPLAY FUNCTION HEX-OF (WS-TOD-VALUE). >GOBACK. > > Peter > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any z/OS sandbox available for a university student I know?
Bill, It's so much more than just colleges. Anybody can download python to their PC and begin writing python in just a few minutes. The same is true for just about every distributed platform operating system and language. When I was 13, I was learning HTML, CGI, Perl, and javascript. In high school, I learned Pascal and QBasic. Neither Pascal or QBasic are flashy or exciting, but I developed a huge passion for programming very early. I would have learned COBOL if I had the capability. Look at cryptocurrencies. There's nothing really flashy or captivating (other than the monetary aspect) like web or video game development with stunning visuals. The majority of the development and interactions are handled as backend transactions, but young kids are clambering to work on it. It's all about culture and perspective. Thank you, Brian Chapman On Tue, Mar 16, 2021 at 3:58 PM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > There are quite a few colleges that offer mainframe classes & lots of > young people working on it. Too many have bought the mainframe is dead > idiocy. For decades. The mainframe still processes the vast majority of > important work and will for decades to come, long after most of us here are > gone. > Yes, plenty of kids are doing more “fun” work. It reminds me of 25 years > ago when Microsoft certification was the hot tech. I’ve seen dozens of fads > come and go that didn’t have the staying power of the good old IBM > mainframe. Visual Basic anyone! Oracle was going to replace DB2 said > numerous “experts”. > IBM fanboy > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, March 16, 2021, 3:45 PM, Brian Chapman > wrote: > > In my opinion, it's a shame that it is this difficult to find a free > academic platform for individuals like the one you described. Master the > Mainframe is a great place to start, but it does not go deep enough. > There's a reason why preteens are writing python, javascript, ruby, etc. > IBM needs to change their perspective and culture to encourage > young individuals to the mainframe. > > > > Thank you, > > Brian Chapman > > > On Tue, Mar 16, 2021 at 12:55 PM Support, DUNNIT SYSTEMS LTD. < > supp...@dunnitsys.com> wrote: > > > Hi all, > > > > I was approached by a university student who wants self study z/OS > > architecture and Assembler - including 64 bit programming - as an > > extra-ciricular activity. The guy is on a shoestring budget. Is there > > anything out there for such an aspiring mainframer? 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any z/OS sandbox available for a university student I know?
In my opinion, it's a shame that it is this difficult to find a free academic platform for individuals like the one you described. Master the Mainframe is a great place to start, but it does not go deep enough. There's a reason why preteens are writing python, javascript, ruby, etc. IBM needs to change their perspective and culture to encourage young individuals to the mainframe. Thank you, Brian Chapman On Tue, Mar 16, 2021 at 12:55 PM Support, DUNNIT SYSTEMS LTD. < supp...@dunnitsys.com> wrote: > Hi all, > > I was approached by a university student who wants self study z/OS > architecture and Assembler - including 64 bit programming - as an > extra-ciricular activity. The guy is on a shoestring budget. Is there > anything out there for such an aspiring mainframer? 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: z/OS Website Template
Jasi, Do you run CICS? If so, have you explored CICS web support using URIMAP and DOCTEMPLATE? https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/applications/designing/dfhp3_doc_template.html Thank you, Brian Chapman On Wed, Mar 10, 2021 at 10:21 AM Jasi Grewal wrote: > Hi, I am looking for z/OS Website Template which could operate using USS > environment and I am looking for a Template with options to provide some > configuration information to the viewers. > I would be grateful if you could share a template and would save me alot > of time in re-designing the initial setup. > > Thank You in advance, > Regards, > Jasi G. > > -- > 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
Querying WLM address space CPU delays
We have an in-house tool that monitors CPU consumption and other performance metrics for address spaces and CICS transactions. This data is summarized every 5 minutes to allow easy querying and comparisons. All of this data is stored in DB2 and we have created some impressive SQL queries to quickly and efficiently display anomalies and critical issues. Our management runs our mainframe near full capacity to achieve "full value" for their processors. Needless to say, we don't always have enough tolerance to allow CPU consumer "outliers". With this tool, researching high CPU consumers that are out of their average have become easy, but we cannot easily determine the perceived impact. Just because an address space is consuming more CPU and the system is at 100% doesn't necessarily mean our customers are perceiving any negative impact. The system could be over its CPU share for the sysplex and another system may have spare CPU to 'steal'. Having the ability to see any delays in our lower service class address spaces would be a great addition. I've been working on a major enhancement to collect CPU delays (I really don't care about other types of delays at the moment) for each address space, but I'm not getting the desired results. I read that IWMRQRY and IWMCOLL appear to be the best services for this solution. However, I found that neither of these services return an ASID or any identifier of an address space. IWMRQRY has an input parameter for ASID, but running this service for every active ASID on the system (roughly 150 on our sandbox system) every quarter second (our WLM interval) is not cheap. Is there a better solution for collecting this data or am I missing something about these WLM services? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Acquire Storage
As a CICS SysProg, this makes me cringe. I would highly recommend rewriting your program to conform to CICS standards, and use CICS to acquire the storage for you. Take a look at the CICS prolog and epilog macros with the DFHEISTG macro. These macros make this super simple and I would wager that it wouldn't require much effort to rewrite your program with these macros. Most importantly (like others have said), don't issue MVS SVC's while running on the CICS QR TCB. You still cause the TCB to be delayed and possibly cause the region to be inoperable. On Wed, Mar 3, 2021, 6:40 PM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > +1 to Binyamin's answer. I have several assembler called subroutines that > run in either CICS or batch but they are all LE enabled (CEEENTRY / CEETERM > macros et. al.). > > LE is your friend here. CICS automatically accommodates LE storage > requests from CICS user storage so operation of the subroutines in CICS or > batch is transparent to the subroutine. > > If they are really small assembler routines that can use the caller's RSA > to save a few regs and use the rest for dynamic storage then you need no > getmain or freemain at all. If the subroutines are more complex and need > full register save and restore then please seriously consider using LE > services. > > If your callers are all COBOL (or other HLL) then you can (usually) safely > assume you are already in an initialized LE environment. > > Performing OS getmain and freemain when you are running under CICS is > fraught with danger and complexity, as Esme points out in her reply. Don't > do it unless you really, really, really need to, and if you still have to > do it then you had better follow all the CICS rules extremely carefully. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Binyamin Dissen > Sent: Wednesday, March 3, 2021 5:09 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Acquire Storage > > I would recommend going to LE and let it take care of things. > > You must consider whether you are using storage protection in which case > you are running in key9. > > On Wed, 3 Mar 2021 21:30:04 + "Savor, Thomas" > <0330b7631be3-dmarc-requ...@listserv.ua.edu> wrote: > > :>Ok, got a question for you CICS Assembler folks. > :> > :>I have a CICS Assembler program that works fineits Re-Entrant of > course. > :>Now I also have some Assembler Sub-programs that can run in Batch. > :>And I want to add them to my Online Program. > :>But...in order to be able to execute in Online it needs to also be > re-entrantwhich is fine for Batch, but Online not so much > :>Now in the sub-program, im executing a STORAGE OBTAIN for the Register > SAVEAREA. > :>But as soon as I try and store the first Register in this acquired > storage area, Protection Exception - Abend (I think it was a S0C4) > :>Anyway, Is there a sub pool to properly acquire storage that makes Batch > and Online Happy or is GETMAIN better or what is the proper way to acquire > storage in both Worlds ?? > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning the basics of SMP/E
Sam, Thanks. Like you, I had to bumble my way through learning SMP/e. I had a few fellow sys progs to lean on, but most of my knowledge was self taught with lots of trial and error. I will definitely give this a read. Something that I have not seen documented is how to create my own SMP/e install for my own software. Is that only provided to ISV's? On Tue, Jan 26, 2021, 1:11 PM Sam Golob wrote: > Dear Folks, > > I was just reviewing an article I wrote in 1988 (a long time ago) > that encapsulates and summarizes my original efforts to learn SMP/E. > > Many of us systems programmers don't have a chance to do system > maintenance, leaving it to "the designated person (or people)". And > also, when breaking in a new person, that person is often given the job > of doing the SMP/E system maintenance. In my experience, the first > exposure to SMP/E is a daunting task. And it is even somewhat > forbidding (to learn SMP/E) for very experienced systems programmers > also, who (somehow) never ever got exposed to it, in their own LONG > experience. > > My personal feeling (in 1988, after five years as a sysprog) was > that, with the PROPER TEACHING, I could have learned, in 3 weeks, what > took me 4 years to learn. > > I didn't want that to happen to anybody else. > > So I wrote an article. Very carefully. > > I just read it over, today. That's why I'm writing this piece. > > IF ANYBODY FEELS THE NEED TO LEARN SMP/E, PLEASE GO TO FILE 014 OF > THE CBT TAPE (www.cbttape.org), and READ THE MEMBER, SMPARTCL. > > Part of the problem in learning SMP/E, is that IBM does not tell > you about its history, and where it came from. In order to really > understand SMP/E, you first must have a grasp of doing a SYSGEN, to > create a new MVS system. We don't do SYSGENs anymore, so this makes it > hard to understand the foundation and structure and purpose and method > of operation, of SMP/E. > > Nevertheless, in that article, I tried to recreate the history, the > best I could. > > BOTTOM LINE. If you want to train someone, or yourself, to do > SMP/E, please first read this article - CBT File 014 - member SMPARTCL. > It is almost guaranteed to make the process simpler. > > Hope this helps. > > All the best of everything to all of you. > > Sincerely, Sam > > > > -- > 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: SDSF NO DATA IN DATA SETS while on the same system
. *
*13.00.49 JOB39680 +PRT417I Dispatch manager detaching task number: 4
program: PORTSOKC*
* BOTTOM OF DATA
Thank you,
Brian Chapman
On Tue, Nov 3, 2020 at 1:05 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Tue, 3 Nov 2020 17:54:22 +, Seymour J Metz wrote:
>
> >SDSF used to behave differently depending on what command you used to get
> to the dataset.
> >
> Ah, yes. I once noticed a disagreement between "DA" and "?". Went to SR;
> was
> told, "Of course." One is based on JQE; the other on JQE (IIRC). I
> assessed that
> as WAD and gave up.
>
> >
> >From: Paul Gilmartin
> >Sent: Tuesday, November 3, 2020 11:29 AM
> >>
> >It has been my experience that instream ("SYSIN"; input) data sets
> >appear empty in SDSF until a job step actually opens or reads them.
> >
> >I don't know whether this is WAD.
>
> -- 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: SDSF NO DATA IN DATA SETS while on the same system
Carmen, There's definitely data on the DD, but for some reason I just can't see it when on the same system. The data will be old (sometimes more than a day) Thank you, Brian Chapman On Tue, Nov 3, 2020 at 10:23 AM Carmen Vitullo wrote: > On Tue, 3 Nov 2020 08:56:24 -0500, Brian Chapman > wrote: > > >I have experienced this issue for years at my site, and I've had no luck > >finding the solution. > > > >If I view a DD of an address space that is running on the same system that > >I am logged into, then I will occasionally receive the 'NO DATA in DATA > >SETS' message in SDSF when I select the output (it can be different DD's). > >I also have similar behaviour when viewing WTO messages in the JESMSGLG. > >I'm unable to see the most recent WTO's, but I can see older ones. If I > log > >onto a different system within the same Sysplex, then I can view all of > the > >output without issue. > > > >I assume this has something to do with viewing the SDSF buffers and some > >setting that is ignoring the most recent buffer. Any help would be greatly > >appreciated. > > > > > > > >Thank you, > > > >Brian Chapman > > > >-- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Brian I see that a lot with address spaces that have not written any data > to a DD, for example, my TCPIP address space lists 8 DD's > ALGPRINT DD for example - other DD's show zero for the record count but > there's data to view. > are you expecting data to be written? has it maybe been spun? > Carmen > > -- > 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
SDSF NO DATA IN DATA SETS while on the same system
I have experienced this issue for years at my site, and I've had no luck finding the solution. If I view a DD of an address space that is running on the same system that I am logged into, then I will occasionally receive the 'NO DATA in DATA SETS' message in SDSF when I select the output (it can be different DD's). I also have similar behaviour when viewing WTO messages in the JESMSGLG. I'm unable to see the most recent WTO's, but I can see older ones. If I log onto a different system within the same Sysplex, then I can view all of the output without issue. I assume this has something to do with viewing the SDSF buffers and some setting that is ignoring the most recent buffer. Any help would be greatly appreciated. Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining program name/number of paramaters from called COBOL program
Correction: you can chain through the resister save area and use the *caller's entry point* (not CEECAA)to chain to the caller's PPA and retrieve the program name. Thank you, Brian Chapman On Tue, Sep 22, 2020 at 7:39 PM Brian Chapman wrote: > If the called program is assembler and the caller is COBOL (linked with > LE), then you can chain through the resister save area and use the CEECAA > to chain to the caller's PPA and retrieve the program name. This method > really only works for called assembler programs; don't bother with COBOL. > > The number of passed parameters is the easy part. Just use the register > save area to read the addresses in register 1 looking for the high order > bit. > > On Tue, Sep 22, 2020, 6:50 PM Joe Monk wrote: > >> Well, here is the answer to at least part of the puzzle, if not all... >> >> "You can find the name of the calling programs from a COBOL V5 or V6 >> program >> at run time by using the LE service CEETBCK. For more information, see >> the z/OS® >> Language Environment® Vendor Interfaces." >> >> >> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SA380688/$file/ceev100_v2r3.pdf >> >> Joe >> >> >> On Tue, Sep 22, 2020 at 5:42 PM Paul Gilmartin < >> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: >> >> > On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote: >> > >> > >Current Enterprise COBOL compilers (and back as far as I know, even >> COBOL >> > F-level from MVT) always mark the last parameter address in the address >> > list with the bit 0 turned on, though I have not researched what current >> > ones do if the last parameter is "BY VALUE". >> > > >> > >Again for current Enterprise COBOL versions, the LE Vendor Interfaces >> > manual available in KC has the PPA1 format and in general how to locate >> it. >> > > >> > The answer depends on agreement between the designers of the calling >> > and called programs. Lacking such agreement there's no general >> > solution. >> > >> > C programs called by a POSIX shell can rely on argc, but only because >> > that's >> > specified in the Standard. >> > >> > -- 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 >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining program name/number of paramaters from called COBOL program
If the called program is assembler and the caller is COBOL (linked with LE), then you can chain through the resister save area and use the CEECAA to chain to the caller's PPA and retrieve the program name. This method really only works for called assembler programs; don't bother with COBOL. The number of passed parameters is the easy part. Just use the register save area to read the addresses in register 1 looking for the high order bit. On Tue, Sep 22, 2020, 6:50 PM Joe Monk wrote: > Well, here is the answer to at least part of the puzzle, if not all... > > "You can find the name of the calling programs from a COBOL V5 or V6 > program > at run time by using the LE service CEETBCK. For more information, see > the z/OS® > Language Environment® Vendor Interfaces." > > > https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SA380688/$file/ceev100_v2r3.pdf > > Joe > > > On Tue, Sep 22, 2020 at 5:42 PM Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > On Tue, 22 Sep 2020 21:51:34 +, Farley, Peter x23353 wrote: > > > > >Current Enterprise COBOL compilers (and back as far as I know, even > COBOL > > F-level from MVT) always mark the last parameter address in the address > > list with the bit 0 turned on, though I have not researched what current > > ones do if the last parameter is "BY VALUE". > > > > > >Again for current Enterprise COBOL versions, the LE Vendor Interfaces > > manual available in KC has the PPA1 format and in general how to locate > it. > > > > > The answer depends on agreement between the designers of the calling > > and called programs. Lacking such agreement there's no general > > solution. > > > > C programs called by a POSIX shell can rely on argc, but only because > > that's > > specified in the Standard. > > > > -- 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXP018I message when STC cancelled
Pierre, I'd love to hear if you find a resolution. I have a process with similar behavior and I receive the same message for each sub-task when it terminates within the ESTAE. Thank you, Brian Chapman On Sun, Sep 20, 2020 at 9:49 AM Charles Mills wrote: > I have always seen that message when one of my dubbed applications ends > abnormally. I have never figured out exactly what the variables are. I > never worried about it, because (a.) it's an "I" message so "nothing to > worry about" and (b.) you're already in an ABEND situation: I focus on > solving the ABEND, not on worrying about the side effects of the ABEND. > > That said, what exactly does the message mean and how can you get rid of > it? I always kind of figured -- without real evidence -- that the cause of > the message was some "unfinished business" on the USS side of things: an > open file, a running process, something of that sort. You might try making > sure that every UNIX file has been closed and every UNIX process has ended. > > I suppose one might try to create a test program that triggered the > message even without an ABEND: what happens if you open a UNIX file and > then end "normally" without closing it? Or starting up a UNIX process and > ending "normally" without stopping the UNIX process? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pierre Fichaud > Sent: Saturday, September 19, 2020 12:49 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: BPXP018I message when STC cancelled > > I have an authorized STC that shuts down normally when it is stopped (/P). > When I cancel the STC, my ESTAEs are driven from newest to oldest. > But I get the message shown below after the ESTAEs are finished. > I do TCP/IP calls using IEZASMI in 2 sub-tasks. > The 2 sub-tasks that do TCPIP cleanup and issue TERMAPI in their ESTAEs. > The thread id is for the JOB STEP TCB. > > I'd like to undub my address space but don't know what to do. > The Unix Callable Services doesn't seem to have a function to do that. > I'd set a SLIP trap but this situation doesn't seem slipable. > Any help would be appreciated. > Thanks in advance, Pierre. > > 14.33.43 STC00663 BPXP018I THREAD 1B216000, IN PROCESS 33620001, > ENDED 039 >039 WITHOUT BEING UNDUBBED WITH COMPLETION CODE 40222000 >039 , AND REASON CODE . > > -- > 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: zSHOP order too large to download
We have a similar problem when applying a new version of CICS. We must have
the AGGRGROW option specified on the USS file system mount for the
directory.
Thank you,
Brian Chapman
On Thu, Jun 4, 2020 at 12:11 PM Carmen Vitullo wrote:
> another thing I'd do is allocate your SMPWORK as a tfs file system that's
> large enough to unpax your order when you do get to the part of the process
> of receiving the order to SMP/E
>
>
>
> MOUNT FILESYSTEM('TMPSMPWK')
> MOUNTPOINT('//local/smpe/workdir')
> TYPE(TFS) /* Filesystem type TFS */
> MODE(RDWR) /* Mounted for read/write */
> PARM('-s 2147380171 -b 1')
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Carmen Vitullo"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Thursday, June 4, 2020 11:02:03 AM
> Subject: Re: zSHOP order too large to download
>
> my DB2 guy has that product installed, he uses the same shopz zfs I've
> allocated for all his orders and has not had any issues with the order
> being too large, I'd still be looking at, if you don't already create a
> separate zfs filesystem just for shopz downloads and ensure it's large
> enough to hold that order; for example
>
>
>
>
>
>
>
> CLUSTER --- OMVS.BCBS.SHOPZ.ZFS
> IN-CAT --- USERCAT.TECHSERV
> HISTORY
> DATASET-OWNER-(NULL) CREATION2015.266
> RELEASE2 EXPIRATION--.000
> SMSDATA
> STORAGECLASS ---OMVS MANAGEMENTCLASS-STANDARD
> DATACLASS ---LINEARE LBACKUP ---.000.
> EATTR-(NULL)
> BWO STATUS-- BWO TIMESTAMP---0 00:00:00.0
> BWO---(NULL)
> .
>
>
>
> ALLOCATION
> SPACE-TYPE--CYLINDER HI-A-RBA-7630848
> SPACE-PRI--1 HI-U-RBA-7618560
> SPACE-SEC500
> VOLUME
>
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Bill Giannelli"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Thursday, June 4, 2020 10:55:01 AM
> Subject: Re: zSHOP order too large to download
>
> My mistake.the product I am trying to download now is Query Monitor
> for Db2 z/OS v3.3
>
> --
> 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
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: deduce program language
Don, Thanks for the info. I'm familiar with the LE Vendor Interfaces, but I guess I need to dig deeper. With all of my test with COBOL and Assembler have been successful. However, it always abends when I intercept a C program; usually with the CEE3550 message. Occasionally it is a 0C4 in the intended program. Does LE have stricter requirements with CEESTART in C programs? Thank you, Brian Chapman On Tue, Oct 1, 2019 at 1:23 PM Don Poitras wrote: > In article t1cmgbfaka497yhff...@mail.gmail.com> you wrote: > > I created a trace facility to intercept external interface calls (MQ, > DB2, > > IMS, etc) and dynamic calls. > > For dynamic calls, I intercept the load request and replace the entry > point > > address with an entry point address of my own program. I then save the > > original entry point address to later branch to the intended program. The > > interception works for assembler and COBOL programs, but it fails for C > > programs. When intercepting a C program, the process abends with a 4038 > > (CEE3550S The DLL cannot be loaded because it does not contain a > CEESTART > > CSECT). > > Is there a write-up on how the program load point is mapped and how to > > deduce the loaded program's language? > > I hoped to clone my assembler intercept program and create a second copy > > that includes the CEESTART macro to resolve this issue. However, I read > > that the CEESTART, CEEMAIN, and CEEFMAIN should not be used within an > > assembler program because it will produce unpredictable behavior. Must I > > write a C program? > > Thank you, > > Brian Chapman > > I'm not sure how COBOL is working for you as it's an LE program the same > as C, but perhaps you're not using standard LE DLL's for your COBOL > programs. CEESTART is not a macro, it's a module/CSECT that gets linked > from the LE bind library when you compile an LE program or DLL. It's > always linked as the entry point as that's where the WSA is allocated > and other housekeeping before the user code is called (either main() or > the DLL function). LE doc is kind of spread all over the place, but > for writing an assembler front-end as you're doing, I think the LE > Vendor Interfaces book is something you should look at. > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/abstract.htm > > -- > Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive > sas...@sas.com (919) 531-5637Cary, NC 27513 > > -- > 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
deduce program language
I created a trace facility to intercept external interface calls (MQ, DB2, IMS, etc) and dynamic calls. For dynamic calls, I intercept the load request and replace the entry point address with an entry point address of my own program. I then save the original entry point address to later branch to the intended program. The interception works for assembler and COBOL programs, but it fails for C programs. When intercepting a C program, the process abends with a 4038 (CEE3550S The DLL cannot be loaded because it does not contain a CEESTART CSECT). Is there a write-up on how the program load point is mapped and how to deduce the loaded program's language? I hoped to clone my assembler intercept program and create a second copy that includes the CEESTART macro to resolve this issue. However, I read that the CEESTART, CEEMAIN, and CEEFMAIN should not be used within an assembler program because it will produce unpredictable behavior. Must I write a C program? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx calls versus branching
Bill, Rexx is a procedural language. Calls to a subroutine that end with a RETURN statement will always branch back to the calling routine. Rexx has the SIGNAL statement that behaves like a GOTO, but it is mostly intended to be used for error handling. If you want the program to terminate after calling the subroutine, replace the RETURN statement with EXIT(0). Thank you, Brian Chapman On Mon, Sep 30, 2019 at 9:38 AM Bill Giannelli wrote: > I am still learning Rexx. Can someone give a simple example of 1) calling > a routine and returning. 2) branching to a routine without returning. > I have a SELECT statement and from the last where clause I want to branch > to a routine without returning. But it keeps returning and falling thru the > end of the SELECT statement. > thanks > Bill > > -- > 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: Submitting batch if you don't have TSO
This topic comes up from time to time at my shop. We have allowed it in the
past, but we try to steer away from any new development with submitting
batch jobs from a region.
The security implications are extremely broad. If you're using a generic
CICS plan exit for DB2 that is defined to use the region userid as plan
authorization, then the region userid has update access to every DB2 table
that is updated by a CICS transaction. If a user submits a QMF or Spufi job
under the region userid, then they can read your DB2 tables. Or even worse,
update them.
The region userid will may also have update access to system datasets. It
will definitely have read access to system datasets (although it may be
limited to CICS specific HLQs).
I would only allow the region to submit jobs under a different user.
Thank you,
Brian Chapman
On Thu, Sep 5, 2019 at 1:59 PM Seymour J Metz wrote:
> <https://www.oed.com/view/Entry/246938>
>
> But there are some good auditors, and if you're lucky enough to have them
> they're your natural allies.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of John McKown
> Sent: Thursday, September 5, 2019 1:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Submitting batch if you don't have TSO
>
> On Thu, Sep 5, 2019 at 12:38 PM Seymour J Metz wrote:
>
> > There's no way that adding a RACF segment would reduce the exposure.
> They
> > need to close the loophole. I'm cheering for the auditor, assuming that
> > he's not brain dead.
> >
>
> Most auditors that I've had to work with are absymally ignorant of z/OS, or
> anything other than Windows. Except one in the past, pre-Windows, who was
> an idiot. He wanted an explanation of every possible exit in MVS and every
> installed product on MVS and what could be done using them. {shudder}
>
>
>
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
>
> --
> I find television very educational. The minute somebody turns it on, I go
> into the library and read a good book
> -- Groucho Marx
>
> Maranatha! <><
> John McKown
>
> --
> 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: Attitude of companies toward mainframers working from home?
Other than changing (or kicking) the hardware, what can be done on-site that can't be done off-site? Most sysprog responsibilities are software. On Thu, Aug 22, 2019, 1:08 PM Chuck Kreiter wrote: > Do you have to also go into the office for "off-hours" support? During an > outage, I would expect that is when you are needed to be most productive so > being on-site seems logical (according to the management explaination). > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of esmie moo > Sent: Thursday, August 22, 2019 12:30 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Attitude of companies toward mainframers working from home? > > We were able to work from home until last year. According to > management's explanation "productivity had deteriorated"Now, we all make > the trek to the office. A lot of people were caught in a bind because > their homes were about 50 -70 miles away from the city center. Others had > to scramble to find daycare for their toddlers. An immense strain and > hardship was exacted on us because we now have to pay expensive > transportation costs etc. But as we are reminded by management to "count > our blessings and we are lucky to have a job". Amen ! > On Thursday, August 22, 2019, 02:55:34 a.m. GMT-4, Ron Hawkins < > ron.hawk...@ipsicsopt.com> wrote: > > Charles, > > It may be a bit different for a test environment, but up until I left > Hitachi last year, I was the only MF person that split time between home > and the office. > > A year later, the MF itself has moved, and none of the testers works on > site. When I left they were located in both US states and another country. > I am doing some contract work for them n and split my time between > Australia and Philippines. > > I liked to have our team to train and work face to face occasionally and > had regular fly-ins of the team for a week. California killed this off as > they want to declare you a tax resident if you spend more than 60 calendar > days in the state. Tell that to someone from Nevada. > > > RON HAWKINS > Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) > m+61 400029610| t: +1 4085625415 | f: +1 4087912585 > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Charles Mills > Sent: Thursday, 22 August 2019 06:46 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [IBM-MAIN] Attitude of companies toward mainframers working from > home? > > I am doing a favor for a friend who is writing a blog article on the above > subject, with an emphasis on the effect of the shrinking mainframe > personnel pool. (This is NOT some disguised headhunter pitch. Reply to the > list or to me personally. I will take full responsibility for "sanitizing" > your e-mail address and so forth out of what I forward to my friend.) > > Does your employer allow mainframe sysprogs and developers to work from > home? > Any particular restrictions or qualifications? > Have they changed their policies specifically to address the shrinking > mainframe personnel pool? > Roughly what percentage of your colleagues work from home? > > Thanks! > > Charles > > -- > 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 > > -- > 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: Mainframes testing
Timothy, While I don't disagree with you, I think that most people here feel that these topics are systemic issues with any platform. Storing unencrypted (or even encrypted) userids and passwords in datasets or files that are not highly restricted is a major liability. I feel that it is disingenuous and unrealistic to say that a mainframe is antiquated or obsolete because of these issues. These are just security 101 topics that are valid for every platform. Thank you, Brian Chapman On Thu, Aug 15, 2019 at 12:26 AM Timothy Sipples wrote: > Let's quote the author directly, OK? I'm going to quote the whole second > section since context is important: > > "2. Data Left Behind > > "Because mainframes were once typically set-up-and-forget systems, they > often contain sensitive data files that should have been deleted after the > deployment phase ended. Certain data should not be written to a space that > just any user can access. > > > "We had one mainframe hacker who logged into the mainframe as an > unprivileged user and immediately saw a highly sensitive file that > contained information she could have used to compromise high-privileged > users in the company’s environment. Files, such as lists of usernames and > passwords and confidential client information, should not remain on the > mainframe, where they are exposed to any type of user who gains physical or > remote access." > > > I don't think this is a particularly well written (or well edited? editors > can sometimes do damage) piece of text -- let me just say that up front. > However, in context, it's not awful. Let's work through this together > > > "Because mainframes were once typically set-up-and-forget systems" > > > That's not the first description that comes to mind of classic mainframes > running MVS, for example. However, that is an excellent description of IBM > AS/400s, and I have seen more than a few references to AS/400s (and IBM i > machines) as "mainframes." That said, the first sentence is my least > favorite. > > > Sentence #2 in this section is quite important for context. > > > "Files, such as lists of usernames and passwords and confidential client > information, should not remain on the mainframe, where they are exposed to > any type of user who gains physical or remote access." > > > I don't think we should automatically blame the author for a stray comma. > Let me oh-so-slightly adjust this sentence, and I'm going to add three > words just to emphasize the problem with that comma: > > > "Files, such as lists of usernames and passwords and confidential client > information, should not remain on the mainframe or anywhere else where they > are exposed to any type of user who gains physical or remote access." > > > It's a very, very reasonable interpretation in context that that's what the > author meant, but the comma, in particular, wasn't at all helpful. No, that > comma certainly shouldn't be there, but it's a comma, and editors (and > sometimes authors) unfortunately make punctuation mistakes. > > > Has anyone who doesn't like this article bothered to contact the author, or > at least try, to suggest improvements? If not, why not? > > > > Timothy Sipples > IT Architect Executive, Industry Solutions, IBM Z & LinuxONE > > > > E-Mail: 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [SUSPECTED SPAM] Re: Instruction speeds
Mike, I believe the difference is related to the fact that branch instructions require a base register and jump does not. Thank you, Brian Chapman On Tue, Aug 13, 2019 at 10:40 AM Mike Shaw wrote: > On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote: > > ..> > > JUMPs are faster than BRANCHes. > > . > > I don't know what you mean by that Chris. > > The various types of Jump instructions are just extended mnemonics for > various types of Branch instructions. JNE generates the same machine > instruction as BNE, etc. > > Do you mean the combined compare and jump instructions like CLGRJ? > > Mike Shaw > MVS/QuickRef Support Group > Chicago-Soft, Ltd. > > -- > 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: Instruction speeds
Thanks Giliad. This is what I was searching for. I understand that the timings in this document are very old and probably wildly inaccurate for today's Z systems, but would it be on a relative scale? Would a LR be twice the speed of a L? Thank you, Brian Chapman On Tue, Aug 13, 2019 at 10:28 AM Giliad Wilf < 00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman > wrote: > > >Hi everyone, > > > >I did some searching, but I didn't find anything that really discussed > this > >on the topic that I'm interested. Is there anything published that > compares > >the cycle times of the most used instructions? > > > >For example; moving an address between areas of storage. I would assume > >that executing a LOAD and STORE would be much quicker than executing a > MVC. > > > >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF > >WORD. > > > >Or does this really matter as much as ordering the instructions so they > are > >optimized for the pipeline? > > > > There used to be, with every new IBM System/360 machine, a "Functional > Characteristics" publication stating "Instruction Times" in microseconds. > Here is one for the IBM System/360 Model 85: > > > http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf > > See page 27. > > -- > 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: Instruction speeds
Thanks everyone for your input. I learned a lot from these responses. I actually meant to write ADD HALFWORD IMMEDIATE in my original email. I was surprised to hear about LA. I had assumed that direct register manipulation was the fastest. On the topic of cache, how do I know that my literal pool is actively cached at execution of a certain instruction? What would cause the hardware to move my literal pool out of cache? Thank you, Brian Chapman On Tue, Aug 13, 2019 at 10:17 AM Charles Mills wrote: > I second everything Chris Blaicher says. You just cannot say how long an > instruction takes. Let me give you an example. (The example is based on > theoretical concepts and has not been tested or benchmarked.) > > Let's say you had some tight loop that was executed many thousands or > millions of times. Let's say you were to insert into the code somewhere the > following instruction: L R0,=F'1', and let's assume that R0 is not in use > at that point so this addition does not change the logic of the program. > > If the insertion were between some compare and an immediately following > conditional jump or branch, and the literal pool were already in the data > cache, then the impact of the added instruction might literally be zero. > The processor could execute it entirely while it was waiting for the > condition code to "settle" anyway. You might in a benchmark see absolutely > no discernible change. So it would be fair to say that the LOAD took no > time at all. > > On the other hand if you inserted it at some other point in the code, > where the literal pool was not in the cache already, or worse, was always > at that point in the flow cached for write access on some other processor, > then the impact might be quite noticeable (assuming enough executions of > the loop -- on a human scale of time, ANY instruction takes no noticeable > time at all). > > With regard to your specific questions, I think of a L/ST sequence as > being faster than an MVC for four aligned bytes, but I am not certain that > is true. (MUCH faster? I seriously doubt it.) Other factors such as those > discussed in my little example above are much more significant. > > I am told that LA is "worse" than other "increment" instructions because > it involves an index register. The instruction to use to increment a > register is undoubtedly AHI for reasons that I believe Chris mentions. AH > (or A) is certainly the worst of the lot because it involves storage access. > > My (admittedly grossly oversimplified) rule of thumb when coding is > "instructions take no time at all; memory accesses take forever." > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Brian Chapman > Sent: Monday, August 12, 2019 5:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Instruction speeds > > Hi everyone, > > I did some searching, but I didn't find anything that really discussed this > on the topic that I'm interested. Is there anything published that compares > the cycle times of the most used instructions? > > For example; moving an address between areas of storage. I would assume > that executing a LOAD and STORE would be much quicker than executing a MVC. > > Or executing a LOAD ADDRESS to increment a register instead of ADD HALF > WORD. > > Or does this really matter as much as ordering the instructions so they are > optimized for the pipeline? > > -- > 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
Instruction speeds
Hi everyone, I did some searching, but I didn't find anything that really discussed this on the topic that I'm interested. Is there anything published that compares the cycle times of the most used instructions? For example; moving an address between areas of storage. I would assume that executing a LOAD and STORE would be much quicker than executing a MVC. Or executing a LOAD ADDRESS to increment a register instead of ADD HALF WORD. Or does this really matter as much as ordering the instructions so they are optimized for the pipeline? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Memo apix product for email
Peter, Are you referring to eMemo by Techserv (was Nexus)? On Fri, Jul 5, 2019, 12:00 PM Peter wrote: > Hi > > Cross posted > > Does anyone uses this product to send email ? > > I am just looking for manual. > > Peter > > -- > 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: QSAM question
Scott, An assembler I/O module would handle this without much effort. Take a look at the EXLST parameter on the file DCB. *DCBEXIT DS0H * * USING DCBXPLST,R1 * * CLHHSI DCBXPRM1,B37 Abend code B37? * * BERECOVER Yes. Ignore abend* *…* *RECOVER DS0H * ** * LTORG * *B37 EQU X'B370' B37 Abend code * ** * *DCBTEMP DCB DDNAME=,DSORG=PS,MACRF=PM,RECFM=FB,LRECL=2960, ** * EXLST=ABNDXLST * ** * *ABNDXLST DCAL1(EXLLASTE+EXLDCBAB),AL3(DCBEXIT) * ** * * IHAEXLST * * DCBD * ** * Thank you, Brian Chapman On Mon, May 6, 2019 at 2:15 PM scott Ford wrote: > All: > > I have a QSAM question. If I have a Cobol program writing to a QSAM file > and it runs out of space on the file, i.e.; SB37 , can i recover from the > SB37 without manual intervention. > A possible condition handler ? > > If I write and Assembler I/O routine to be called passing the data to and > writing to the QSAM file, the same question, my assumption is "yes" and can > someone point me to the manual I assume it DFSMSdfp working with datasets > ... > > Regards, > Scott > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > www.idmworks.com > > scott.f...@idmworks.com > > Blog: www.idmworks.com/blog > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from > disclosure. If the reader of this message is not the intended recipient, > you are hereby notified that any dissemination, distribution, copying or > use of this message and any attachment is strictly prohibited. If you have > received this message in error, please notify us immediately by replying to > the message and permanently delete it from your computer and destroy any > printout thereof.* > > -- > 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: COBOL 6.2 and ARCH(12)
Charles, Thanks for the explanation. Our system IGYCOPT specifies ARCH=*8. We are only experiencing this issue on our production machine. We clone our machine for DR, but our test systems are never started so the debugging tool would never be used on this machine. Simulation debuggers are not allowed on our production systems. Thank you, Brian Chapman On Mon, May 6, 2019 at 10:34 AM Charles Mills wrote: > > How does z/OS handle a situation where two COBOL programs that are > compiled > > at different ARCH levels and part of the same LE enclave? Since the > vendor > > code receives execution first, does it determine the enclave level? > > I don't think an enclave HAS an ARCH level. ARCH is a compiler parm. If > you were writing a compiler, your compiler code would say "can I use > machine instruction XYZ? Nope, user said ARCH(n), so no can do." The code > you emitted would be fixed (of course): it would never, ever have an > instruction XYZ in it. If the user ran it on a zWhatever, it would still be > devoid of XYZ instructions. The enclave does not have an ARCH level, the > various programs running there either do or do not include instruction XYZ. > > > I'm not > > sure what ARCH level the vendor compiles their COBOL code (if they have > > any). > > They need to know. I was until very recently responsible for a vendor > product written in C++. There was a conscious management decision to > support customers back through a z9, so I compiled ARCH(7). End of story. I > did not pick some new ARCH level that appealed to me that day. > > Question: did you possibly customize or parametize the debugger for a z14 > during installation, and then clone that installation over to your older DR > machine? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Brian Chapman > Sent: Monday, May 6, 2019 6:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > I verified a few of my recent COBOL listings, and they all have ARCH(8) > specified. > > Our applications developers claim that this issue only occurs when they run > their code through the debugger. It apparently never occurs outside the > debugger. The issue has been very intermittent, so it hasn't been easy to > replicate but we have dumps from most of the 0C1 or 0C4 abends. > > How does z/OS handle a situation where two COBOL programs that are compiled > at different ARCH levels and part of the same LE enclave? Since the vendor > code receives execution first, does it determine the enclave level? I'm not > sure what ARCH level the vendor compiles their COBOL code (if they have > any). > > > Thank you, > > Brian Chapman > > -- > 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: COBOL 6.2 and ARCH(12)
I verified a few of my recent COBOL listings, and they all have ARCH(8) specified. Our applications developers claim that this issue only occurs when they run their code through the debugger. It apparently never occurs outside the debugger. The issue has been very intermittent, so it hasn't been easy to replicate but we have dumps from most of the 0C1 or 0C4 abends. How does z/OS handle a situation where two COBOL programs that are compiled at different ARCH levels and part of the same LE enclave? Since the vendor code receives execution first, does it determine the enclave level? I'm not sure what ARCH level the vendor compiles their COBOL code (if they have any). Thank you, Brian Chapman On Mon, May 6, 2019 at 9:01 AM John Abell < john.ab...@intnlsoftwareproducts.com> wrote: > Your should have something similar to the following in the COBOL listing > where I have used ARCH(11). > > Invocation parameters: > OPTFILE > Options from SYSOPTF: > ARCH(11) > ARITH(COMPAT) > DATA(31) > . > . > . > > John T. Abell > Tel:800-295-7608Option 4 > President > International: 1-416-593-5578 Option 4 > E-mail: john.ab...@intnlsoftwareproducts.com > Fax:800-295-7609 > > International: 1-416-593-5579 > > > International Software Products > www.ispinfo.com > > This email may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review, use, retention, distribution > or disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive on behalf of the named recipient), > please contact the sender by reply email and delete all copies of this > message. Also,email is susceptible to data corruption, interception, > tampering, unauthorized amendment and viruses. We only send and receive > emails on the basis that we are not liable for any such corruption, > interception, tampering, amendment or viruses or any consequence thereof. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: Monday, May 06, 2019 8:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > The actual arch level should be somewhere in the Job listing from the > Cobol Compile. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of John Abell > Sent: Saturday, May 4, 2019 9:44 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > I am a bit behind on this issue so maybe you have tried some of the below. > > I am puzzled by this unless the ARCH parm is not taken by the compiler for > some reason. Do you have the same problem using the DEFAULT ARCH value? > > Generate the assembler listing and then see if the S0C1 or S0C4 actually > happens in the COBOL code. Also check the ARCH value in the listing. Look > for Vector instructions, in the assembler listing for starters. I did this > for the C modules compiled under z/OS 2.3 and ARCH(12) and the new Vector > instructions were in the listing. They were not there using earlier > versions of the compiler. I generate C code all of the time using the ARCH > and TUNEs value for the client's machine. The code is compiled on a z14. > Client's with z12s and z13s report no issues. This is all using LE. > > One item of interest, maybe, is that the C code compiled with ARCH(12) on > z/OS 2.3 runs without issue on z/OS 2.2 and 2.2's LE on a z14. > > Can you run without the 3rd party software and see if your code runs? > > John T. Abell > Tel:800-295-7608Option 4 > President > International: 1-416-593-5578 Option 4 > E-mail: john.ab...@intnlsoftwareproducts.com > Fax:800-295-7609 > > International: 1-416-593-5579 > > > International Software Products > > https://apc01.safelinks.protection.outlook.com/?url=www.ispinfo.comdata=02%7C01%7Callan.staller%40HCL.COM%7C94623be694344a0455d808d6d09f07a0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636925778808536522sdata=hIdc5QKlumv6gBEJu8VMRPH7iXIE42%2BgqvIYR5yhpZY%3Dreserved=0 > > This email may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review, use, retention, distribution > or disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive on behalf of the named recipient), > please contact the sender by reply email and delete all copies of this > message. Also,email is susceptible to data corruption, interception, > tampering, unauthorized amendment and viruses. We only send and receive > emails on the basis that we ar
Re: COBOL 6.2 and ARCH(12) [EXTERNAL]
This article from IBM agrees with your thoughts and everything else I've read. I can't find anything that confirms the vendor's statement. https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=897=ENUS217-323 On Fri, May 3, 2019, 5:20 PM Feller, Paul wrote: > It is my understanding that if you set the ARCH level to something lower > than the machine type you are running on it should not use any of the new > machine instructions. If what the vendor says is truly what is happening > then I would think a question to IBM would be in order. > > Thanks.. > > Paul Feller > AGT Mainframe Technical Support > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Brian Chapman > Sent: Friday, May 03, 2019 2:58 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: COBOL 6.2 and ARCH(12) [EXTERNAL] > > We have a vendor debugging product that is constantly causing 0C1 and 0C4 > abends since we have upgraded to COBOL 6.2. It also caused these abends > when we were at COBOL 4,2, but the abend rate has grown considerably after > the upgrade. > > The vendor has produced countless patches, but so far they have not > resolved the issues. We were notified today that they believe they > understand the issue. They are stating that even though our COBOL compiler > is set with ARCH(8) (to support our DRE machine), LE run-time is > recognizing that the program is COBOL 6.2, running on a z14, and > automatically switch the ARCH level to ARCH(12). They believe the run-time > execution is exploiting the new Vector Packed Decimal Facility and > producing erratic behavior. > > I searched through several presentations and IBM manuals for COBOL 6.2, > and everything I have found states that a recompile with ARCH(12) is > required to take advantage of the new facility. Is the vendor correct? > > > > Thank you, > > Brian Chapman > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Please note: This message originated outside your organization. Please > use caution when opening links or attachments. > > -- > 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
COBOL 6.2 and ARCH(12)
We have a vendor debugging product that is constantly causing 0C1 and 0C4 abends since we have upgraded to COBOL 6.2. It also caused these abends when we were at COBOL 4,2, but the abend rate has grown considerably after the upgrade. The vendor has produced countless patches, but so far they have not resolved the issues. We were notified today that they believe they understand the issue. They are stating that even though our COBOL compiler is set with ARCH(8) (to support our DRE machine), LE run-time is recognizing that the program is COBOL 6.2, running on a z14, and automatically switch the ARCH level to ARCH(12). They believe the run-time execution is exploiting the new Vector Packed Decimal Facility and producing erratic behavior. I searched through several presentations and IBM manuals for COBOL 6.2, and everything I have found states that a recompile with ARCH(12) is required to take advantage of the new facility. Is the vendor correct? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Authorized and unauthorized in same address space
*Doesn't CICS turn off authorization before executing transactions? * I believe that is true. I believe it disables authorization before the PLT (first opportunity for user code). Thank you, Brian Chapman On Thu, Mar 28, 2019 at 12:18 PM Seymour J Metz wrote: > AFAIK, no IBM code runs APF authorized and unauthorized code concurrently > in the same address space, but rather makes the unauthorized code > nondispatchable while the authorized code is running. Doesn't CICS turn off > authorization before executing transactions? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Brian Chapman > Sent: Thursday, March 28, 2019 9:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Authorized and unauthorized in same address space > > Searching through the archives, I quickly saw that this has been a repeat > heated discussion, but > all of the discussions seem to ignore the fact that CICS initializes as an > authorized address space, performs authorized work, and then disables > authorization to load unathorized programs from the DFHRPL tasklib. It does > what so many people deem to be a security integrity violation. > > I have an unauthorized address space that collects information from the > system and uses MQ or CICS EXCI (if MQ is unavailable) to transport the > data to another address space which stores the data to DB2. Having the > ability to execute authorize services would greatly increase the > functionality of this address space. Since neither of these transport > mechanisms are authorized, i cannot run authorized in the current setup. > > The idea is to execute the authorized requests as non-system supervisor PC > routines. One of the PC routines would be to simply disable JSCBAUTH (ONLY > disable. NEVER enable). Before invoking this PC routine, I perform a > MODESET to switch back to problem state and key 8. The only authorized > services performed before this switch would be the LXRES, ETDEF, ETCRE, and > ETCON services to build the PC routines. After invoking the JSCBAUTH > disable PC routine from the job step program, I cannot switch back. > Invoking a MODESET after the switch abends address space with a 047. > > From this point forward, all of the ATTACH and LOAD services are performed > with the supplied tasklib. The unauthorized code is COBOL. Before this > program is invoked, it initializes LE and replaces the default CEEZLOD and > CEEZDEL with my own version that loads from the tasklib. > > > Thank you, > > Brian Chapman > > -- > 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: Authorized and unauthorized in same address space
*2. Run authorized tasks in parallel with unauthorized tasks - bigger issue.You cannot use any user key storage - even the passed save area or the LEanchor. No LM 14,12,12(13) at the end of your module - use SVC 3. AllSTORAGE/GETMAIN to protected subpools. And if you will be fetching fetchprotected storage, you must block the unauthorized tasks while doing it so* *that they cannot examine your RBs and possible see storage contents. * Binjamin, Are supervisor PC routines included? The save areas and PR instruction are handled by z/OS. I definitely see the exposure of modifying user passed data without any validation, but this same exposure is present in space switching PC routines hosted by an authorized address space. Thank you, Brian Chapman On Thu, Mar 28, 2019 at 10:45 AM Binyamin Dissen wrote: > Two separate things: > > 1. Prepare user supplied authorized services and then change the job to > unauthorized - perfectly fine,as long as you follow standard authorized > service logic, i.e., never trust any user supplied address and use > protected > storage as your worrkarea. > > 2. Run authorized tasks in parallel with unauthorized tasks - bigger issue. > You cannot use any user key storage - even the passed save area or the LE > anchor. No LM 14,12,12(13) at the end of your module - use SVC 3. All > STORAGE/GETMAIN to protected subpools. And if you will be fetching fetch > protected storage, you must block the unauthorized tasks while doing it so > that they cannot examine your RBs and possible see storage contents. > > On Thu, 28 Mar 2019 09:06:02 -0400 Brian Chapman > wrote: > > :>Searching through the archives, I quickly saw that this has been a repeat > :>heated discussion, but > :>all of the discussions seem to ignore the fact that CICS initializes as > an > :>authorized address space, performs authorized work, and then disables > :>authorization to load unathorized programs from the DFHRPL tasklib. It > does > :>what so many people deem to be a security integrity violation. > :> > :>I have an unauthorized address space that collects information from the > :>system and uses MQ or CICS EXCI (if MQ is unavailable) to transport the > :>data to another address space which stores the data to DB2. Having the > :>ability to execute authorize services would greatly increase the > :>functionality of this address space. Since neither of these transport > :>mechanisms are authorized, i cannot run authorized in the current setup. > :> > :>The idea is to execute the authorized requests as non-system supervisor > PC > :>routines. One of the PC routines would be to simply disable JSCBAUTH > (ONLY > :>disable. NEVER enable). Before invoking this PC routine, I perform a > :>MODESET to switch back to problem state and key 8. The only authorized > :>services performed before this switch would be the LXRES, ETDEF, ETCRE, > and > :>ETCON services to build the PC routines. After invoking the JSCBAUTH > :>disable PC routine from the job step program, I cannot switch back. > :>Invoking a MODESET after the switch abends address space with a 047. > :> > :>From this point forward, all of the ATTACH and LOAD services are > performed > :>with the supplied tasklib. The unauthorized code is COBOL. Before this > :>program is invoked, it initializes LE and replaces the default CEEZLOD > and > :>CEEZDEL with my own version that loads from the tasklib. > :> > :> > :>Thank you, > :> > :>Brian Chapman > :> > :>-- > :>For IBM-MAIN subscribe / signoff / archive access instructions, > :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > 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
Authorized and unauthorized in same address space
Searching through the archives, I quickly saw that this has been a repeat heated discussion, but all of the discussions seem to ignore the fact that CICS initializes as an authorized address space, performs authorized work, and then disables authorization to load unathorized programs from the DFHRPL tasklib. It does what so many people deem to be a security integrity violation. I have an unauthorized address space that collects information from the system and uses MQ or CICS EXCI (if MQ is unavailable) to transport the data to another address space which stores the data to DB2. Having the ability to execute authorize services would greatly increase the functionality of this address space. Since neither of these transport mechanisms are authorized, i cannot run authorized in the current setup. The idea is to execute the authorized requests as non-system supervisor PC routines. One of the PC routines would be to simply disable JSCBAUTH (ONLY disable. NEVER enable). Before invoking this PC routine, I perform a MODESET to switch back to problem state and key 8. The only authorized services performed before this switch would be the LXRES, ETDEF, ETCRE, and ETCON services to build the PC routines. After invoking the JSCBAUTH disable PC routine from the job step program, I cannot switch back. Invoking a MODESET after the switch abends address space with a 047. >From this point forward, all of the ATTACH and LOAD services are performed with the supplied tasklib. The unauthorized code is COBOL. Before this program is invoked, it initializes LE and replaces the default CEEZLOD and CEEZDEL with my own version that loads from the tasklib. Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time and zIIP
Thanks Peter. Here is the IBM document that I based my assumptions of the SDSF fields. *CPU-Time* Accumulated CPU time consumed by and on behalf of the address space, for the current job step, in seconds. SDSF obtains this value from RMF, as follows: ASCBEJST + ASCBSRBT + ASSBASST (source field R791TCPU) where *ASCBEJST* is elapsed job step time *ASCBSRBT* is accumulated SRB time *ASSBASST* is the CPU time consumed by preemptible class SRBs running on behalf of this address space, in milliseconds *ECPU-Time* Total CPU time consumed by and within the address space, for the current job step, in seconds. SDSF obtains this value from RMF, as follows: ASCBEJST + ASCBSRBT + ASSBPHTM (source field R791TCPC) where *ASCBEJST* is elapsed job step time *ASCBSRBT* is accumulated SRB time *ASSBPHTM* is the CPU time consumed by preemptible class SRBs running in this address space, in milliseconds (threads plus enclaves) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zosmfsdsf.jobresources.help.doc/izusfhpJobActiveSystemUse.html I assumed since SDSF compartmentalized the zIIP, zAAP, and zICP times that they must not be included in the CPU-Time field. Like Carmen noted, when I add the GCP-Time, zIIP-Time, zAAP-Time, and zICP-Time it does not calculate out to be the same as the CPU-Time or ECPU-Time amount. Thank you, Brian Chapman On Tue, Feb 26, 2019 at 9:21 AM Peter Relson wrote: > If the comment is correct that the SDSF display is using ASCBEJST, then > the statement > "ZIIP is not reported as part of CPU." > is not correct with respect to that display. > > ASCBEJST includes all time, whether standard CP or zIIP. > There are additional fields, such as ASSB_TIME_ON_CP, that do not include > zIIP. > > Fields in SMF records do use ASSB_TIME_ON_CP rather than ASCBEJST. For > those fields, the statement is correct. > > I wasn't sure in what way the OP concluded that zIIP was or was not > included when he wrote "must not be true" and "I'm thinking it is not". > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CPU time and zIIP
Hello, I'm trying to understand the CPU and ECPU times displayed on SDSF and the relation to zIIP processing time. For example, here is a CICS region running a Java web service. *CPU-Time ECPU-Time GCP-Time zIIP-Time zICP-Time zIIP-NTime* * 164.42166.2890.89 30.21 3.42 71.29* Here is a CICS transaction executing in the region to display various ASSB fields. CPU DISPLAY * *ASCBEJST. . . . . . : 162.20* *ASCBSRBT. . . . . . :2.23* *ASSBASST. . . . . . : .00* *ASSBPHTM. . . . . . :1.86* *CPU . . . . . . . . : 164.43 (ASCBEJST + ASCBSRBT + ASSBASST)* *ECPU. . . . . . . . : 166.29 (ASCBEJST + ASCBSRBT + ASSBPHTM)* *ASSB-TIME-ON-ZIIP . : 30.22* *ASSB-ZIIP-ENCT. . . :1.60* *ASSB-ZIIP-PHTM. . . :1.60* *ASSB-ASST-TIME-ON-CP: .00* The CPU-Time, ECPU-Time, and zIIP-time match (as close as humanly possible to switch 3270 emulators and press enter). I was under the assumption that ECPU also included time spent on zIIPs, but that must not be true. Is zIIP time included in CPU and ECPU? I'm thinking it is not. Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARV64 - why ABEND rather than return with reason code?
I found this to be the most irritating aspect of working with 64 bit areas. On Fri, Jan 25, 2019, 5:23 PM Charles Mills I have an application that uses IARV64 REQUEST=GETCOMMON,COND=YES. I have > tested with an unreasonable request size and gotten a return with a reason > code as expected. > > I recently had the IARV64 fail, due to my bug that I have located. But what > surprised me is that I got an SDC2 ABEND rather than a return with a reason > code. I would rather get a return because I can handle it more neatly than > an ABEND (although yes, I do catch the ABEND with ESTAE). Why the ABEND > rather than a return? Can I force a return rather than an ABEND? Is this > documented somewhere? (I obviously did not see it.) > > In case it matters the reason code in question is xx0042yy, Guard size is > greater than object size. (And again, I have located the underlying bug; I > don't need help with that; just with "why ABEND rather than return?") > > z/OS V2R2 and V2R3, if that matters. > > Charles > > -- > 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: Concurrent Server Task Dispatch issue multitasking issue
1. Are you checking the COMM ECB after every wait? Even after a subtask post the main task's ECB or any other ECB in your list? I've had problems with subtasks posting the main task and not checking the COMM ECB after servicing the subtask request and missing console commands. 2. Double check which ECB in your ECB list has the high order bit set. I've added more ECBs in my list and forgot to move the high order bit flip. On Jan 5, 2019 6:26 PM, "Joseph Reichman" wrote: First off it is being posted I saw a X’48’ in the first byte the operative bit being the 4 I am doing the wto on timeout from both selects and the problem is that the main task doesn’t get control Thanks > On Jan 5, 2019, at 12:20 AM, Brian Westerman < brian_wester...@syzygyinc.com> wrote: > > When you test the ECB is anything being posted? Is it possible that your subtasks are actually sharing the ECBLIST for other use and they are clearing it for you? > > It would be interesting to have all of your tasks (main and sub) wto when they are posted so that you can see where you are when the post happens. Possibly you are in a subtask, it gets posted and that subtask sees that it's not "his" data, so clears things and moves on. I don't share the ECBLIST between the main and subtask, so I'm not sure what happens if you do, but it always seemed to me to be asking for trouble. > > Brian > > -- > 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: System level coding examples
Thanks Don. I didn't realize that the listserv even existed. I thought the Google newsgroup was the primary forum. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
