Re: multi-line STDPARM shell script for BPXBATCH
On 2019-10-30 4:45 AM, Paul Gilmartin wrote: On 2019-10-07 2:06 AM, Jon Perryman wrote: I'm saying that IBM can't fix this problem because the problem lies with Unix shell design. IBM can and have fixed the problem! BPXBATCH is so bad they wrote a replacement AOPBATCH which works just as Kirk describes. IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator. How do you know? Do you work for IBM? Only the village idiot would consider BPXBATCH not to be *bad* :) Maybe you've never been unlucky enough to have to use it! AOPBATCH simply changes the problems. IBM doesn't need to address those problems because they are outside the scope of AOP. Oh, my. True Blue! Reminds me of a lawyer defending a hopeless case! An often-criticized limitation of BPXBATCH is that it does not tolerate instream data sets or classic data sets as STDIN. AOPBATCH removes that limitation and introduces no new limitations (AFAIK?) Stacked commands using a semicolon separator do not allow "#" comments. Comments are widely considered a valuable aspect of coding technique. To paraphrase; BPXBATCH sucks! I have used COZBATCH for years but recently had a requirement to be able to ship something similar so we could install a web application from a PAX member using a batch job. I wrote my own batch shell utility using a tip from Kirk Wolf. It was very simple to implement, another reason why it's so disappointing that BPXBATCH is so wretched. Anyway, we already had this conversation 10 years ago and it's not worth dragging it up again. Are you arguing for a semantic distinction between "fixing a problem" and "removing an onerous limitation"? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
So according to: "20 The routine_name contains only blanks and the routine_entry was zero. The PreInit table was not updated." https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/ceeam141.htm Joe On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman wrote: > The listing has the SYSSTATE set AMODE 64 > The LISTPSW indicates botH the EA and BA BITS of the PSW as one > indicating AMODE 64 at location F8 right before the call CELQPIPI > > > CEEWQPIP: LOADing CELQPIPI > CEEWQPIP: Doing CELQPIPI INIT_MAIN > IKJ57024I AT +F6 > TEST > istpsw > IKJ57652I PSW LOCATED AT 8BA068 > XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR > 01118 1101 00 00 1 1 1F7010F6 > > TEST > t +f8 > TEST > o > CEEWQLOD: Called to LOAD "TEST64A " > IKJ57024I AT +F8 > TEST > > The program is AMODE 64 > > TEST64A0D30 0001D6 0064 > ANY > > This is a listing of the table > +CEEXPTBL DCCL8'CELQPTBL'Eyecatcher > + DCA(CELQPIT0058) Number of e > + DCF'16'Entry size > + DCF'100' Version > ice routines > > Source Statement HLASM R6 > + DCAL1(0) > + DC3X'00' >CELQPITY TEST64A,0 ically load CE > + DCCL8'TEST64A' Name, set t > + DCAD(0)Load dblwd >CELQPITS , End of CELQPIP > +CELQPIT0058 EQU 1 Number of e > * > Here is the listing of TEST64A > > TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > YREGS > *LOAD EP=CEETEST > *LRR15,R0 > *BASR R14,R15 > CELQCALL opendata,(SYSADATA),WORKREG=10 > XR R15,R15 > CELQEPLG > SYSADATA DC CL8'SYSADATA' > *CEEPDDA opendata,SCOPE=IMPORT > PARM1DC A(COMMANDS) > PARM2DC A(FEEDBACK) > > Here is the link > For TEST64A > > //* > //* LINK EDIT THE PROGRAM * > //* > //STEP0200 EXEC PGM=IEWL,COND=(0,LT,STEP0100), > // PARM='AMODE(64),LIST,MAP,XREF,CASE=MIXED,DYNAM=DLL' > //SYSPRINT DD SYSOUT=* > //SYSDEFSD DD SYSOUT=* > //OBJ DD DSN=&,DISP=(OLD,PASS) > //SYSLIB DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB > // DD DISP=SHR,DSN=CEE.SCEEBND2 > // DD DISP=SHR,DSN=CEE.SCEELKED > //SYSLMOD DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB > //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,2)),DSN= > //SYSPRINT DD SYSOUT=*,DCB=(RECFM=FB,BLKSIZE=3509) > //SYSLIN DD * > IMPORT CODE64,'SYSADATA','opendata' > INCLUDE OBJ(TEST64A) > ENTRY TEST64A > NAME TEST64A(R) > > > > > > 84 * >85 > ** >86 * > 07B0 87 CEEWQPIP CSECT, >88 CEEWQPIP AMODE64 >89 CEEWQPIP RMODE31 >90 SYSSTATE > AMODE64=YES >91+*THE VALUE OF > SYSSTATE IS NOW SET TO ASCENV=P AMODE64=YES ARCHLX01-SYSSTATE > + VL=2 > OSREL= > 010E 92 SAM64, >93 * >94 * >95 *Standard 64-bit > entry linkage >96 * > - >97 * > 0002 EBEC D008 0024 0008 98 STMG > R14,R12,SAVF4SAG64RS14-SAVF4SA(R13) Save caller regs > 0008 0DB0 99 BASR R11,0 > Set up basereg > R:B 000A 100 USING*,R11 > Addressabliity > 101 GETMAIN > RU,LV=DSA_L Obtain DSA > 000A 103+ DS0H > @P5C 01-GETMAIN > 000A 104+IHB0002C DS 0H > 01-GETMAIN > 000A 5800 B36E 0378105+ L > 0,=A(DSA_L)LOAD LENGTH 01-GETMAIN > 000E 58F0 B372 037C
Re: CPACF for TN3270 encryption
Yes, if you use the policy agent (PAGENT). ITschak On Tue, Oct 29, 2019 at 11:03 AM Jake Anderson wrote: > Hi > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > Just trying to understand its functionality and has anyone tried this > functionality implementated for TN3270 connectivity. > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses TLS 1.2 via IBM’s policy agent. On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson wrote: > Hi > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > Just trying to understand its functionality and has anyone tried this > functionality implementated for TN3270 connectivity. > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: zOS 2.4 migration guide
Brian, Thanks for pointing that out. Wondering why IBM couldn’t have designed some automated method to determine if the KCindex needs to be rebuilt or not? Now the issue will be to remember to let it rebuild after a maintenance cycle? Or z/OS release change? How will I know when it *needs* to be rebuilt? I want to set this just to streamline the startup, but not at the expense of some future "headscratching" trying to figure out why something isn’t updating _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Tuesday, October 29, 2019 12:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXT] Re: zOS 2.4 migration guide **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** There is an APAR that provides a new setting (KCINDEX=N) that you use (after the first time you start zosmf), that keeps the i/o's down to a much more reasonable level. Our clients that have small single frame systems (z13s, z14-rz1), find that it cuts the startup time by almost 40%. The official IBM speak is: "With APAR PH06678, a new option "KCINDEX" is provided in IZUSVR. If "KCINDEX=N" is provided when starting IZUSVR, the embedded knowledge center will not build its index. As index is not rebuilt, startup time has 12% improvement. CPU usage has 24% improvement. I/O has 16% improvement. " Remember, the first time you start it though it's going to be slow because you can't use the KCINDEX=N until after that first time. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
I can’t say I’m 100% sure but highly suspect it does. We don’t have our crypto express cards configured yet so I know it’s not using them. On Tue, Oct 29, 2019 at 4:44 AM Jake Anderson wrote: > "We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses > TLS 1.2 via IBM’s policy agent" > > All its workload goes to CPACF ? > > On Tue, 29 Oct, 2019, 1:42 PM Michael Babcock, > wrote: > > > We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses > > TLS 1.2 via IBM’s policy agent. > > > > On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson > > wrote: > > > > > Hi > > > > > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > > > > > Just trying to understand its functionality and has anyone tried this > > > functionality implementated for TN3270 connectivity. > > > > > > Jake > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > > Michael Babcock > > OneMain Financial > > z/OS Systems Programmer, Lead > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
Why do you need a DLL? Can you just use PIPI to call a static program? On 2019-10-29 8:15 PM, Joseph Reichman wrote: This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s a good idea to try to use add_entry After init_sub/MAIN This is the program I trying to initiate as in Assembler LE 64 bit prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I was thinking CELQPIPI would resolve these issues Thanks TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A YREGS *LOAD EP=CEETEST *LRR15,R0 *BASR R14,R15 CELQCALL opendata,(SYSADATA),WORKREG=10 XR R15,R15 CELQEPLG SYSADATA DC CL8'SYSADATA' *CEEPDDA opendata,SCOPE=IMPORT PARM1DC A(COMMANDS) PARM2DC A(FEEDBACK) DS 0H DC H'9' COMMANDS DC C'AT ENTRY ' FEEDBACK DS CL12 CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA CEECAA MAPPING OF THE COMMON ANCHOR AREA *LLPPA CEEPPA WORKAREA DSECT DS 0D WORKSIZE EQU *-WORKAREA *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK END -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Tuesday, October 29, 2019 3:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN So according to: "20 The routine_name contains only blanks and the routine_entry was zero. The PreInit table was not updated." https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/ceeam141.htm Joe On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman wrote: The listing has the SYSSTATE set AMODE 64 The LISTPSW indicates botH the EA and BA BITS of the PSW as one indicating AMODE 64 at location F8 right before the call CELQPIPI CEEWQPIP: LOADing CELQPIPI CEEWQPIP: Doing CELQPIPI INIT_MAIN IKJ57024I AT +F6 TEST istpsw IKJ57652I PSW LOCATED AT 8BA068 XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR 01118 1101 00 00 1 1 1F7010F6 TEST t +f8 TEST o CEEWQLOD: Called to LOAD "TEST64A " IKJ57024I AT +F8 TEST The program is AMODE 64 TEST64A0D30 0001D6 0064 ANY This is a listing of the table +CEEXPTBL DCCL8'CELQPTBL'Eyecatcher + DCA(CELQPIT0058) Number of e + DCF'16'Entry size + DCF'100' Version ice routines Source Statement HLASM R6 + DCAL1(0) + DC3X'00' CELQPITY TEST64A,0 ically load CE + DCCL8'TEST64A' Name, set t + DCAD(0)Load dblwd CELQPITS , End of CELQPIP +CELQPIT0058 EQU 1 Number of e * Here is the listing of TEST64A TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A YREGS *LOAD EP=CEETEST *LRR15,R0 *BASR R14,R15 CELQCALL opendata,(SYSADATA),WORKREG=10 XR R15,R15 CELQEPLG SYSADATA DC CL8'SYSADATA' *CEEPDDA opendata,SCOPE=IMPORT PARM1DC A(COMMANDS) PARM2DC A(FEEDBACK) Here is the link For TEST64A //* //* LINK EDIT THE PROGRAM * //* //STEP0200 EXEC PGM=IEWL,COND=(0,LT,STEP0100), // PARM='AMODE(64),LIST,MAP,XREF,CASE=MIXED,DYNAM=DLL' //SYSPRINT DD SYSOUT=* //SYSDEFSD DD SYSOUT=* //OBJ DD DSN=&,DISP=(OLD,PASS) //SYSLIB DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB // DD DISP=SHR,DSN=CEE.SCEEBND2 // DD DISP=SHR,DSN=CEE.SCEELKED //SYSLMOD DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,2)),DSN= //SYSPRINT DD SYSOUT=*,DCB=(RECFM=FB,BLKSIZE=3509) //SYSLIN DD * IMPORT CODE64,'SYSADATA','opendata' INCLUDE OBJ(TEST64A) ENTRY TEST64A NAME TEST64A(R) 84 * 85 ** 86 * 07B0 87 CEEWQPIP CSECT, 88 CEEWQPIP AMODE64 89 CEEWQPIP RMODE31 90 SYSSTATE AMODE64=YES 91+*THE VALUE OF SYSSTATE IS NOW SET TO ASCENV=P AMODE64=YES ARCHLX01-SYSSTATE
CPACF for TN3270 encryption
Hi Is it possible to encrypt TN3270 connectivity using CPACF ? Just trying to understand its functionality and has anyone tried this functionality implementated for TN3270 connectivity. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
Try this aging SHARE presentation from 2014. You'll probably find a more recent one if your search the web or SHARE. https://share.confex.com/share/123/webprogram/Handout/Session15660/SharePittsburgh15660_Aug2014_System_SSL_And_Crypto.pdf Mike Wawiorko This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Execution Services Limited provides support and administrative services across Barclays group. Barclays Execution Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale Financial Services Limited is authorised and regulated by the Financial Conduct Authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s a good idea to try to use add_entry After init_sub/MAIN This is the program I trying to initiate as in Assembler LE 64 bit prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I was thinking CELQPIPI would resolve these issues Thanks TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A YREGS *LOAD EP=CEETEST *LRR15,R0 *BASR R14,R15 CELQCALL opendata,(SYSADATA),WORKREG=10 XR R15,R15 CELQEPLG SYSADATA DC CL8'SYSADATA' *CEEPDDA opendata,SCOPE=IMPORT PARM1DC A(COMMANDS) PARM2DC A(FEEDBACK) DS 0H DC H'9' COMMANDS DC C'AT ENTRY ' FEEDBACK DS CL12 CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA CEECAA MAPPING OF THE COMMON ANCHOR AREA *LLPPA CEEPPA WORKAREA DSECT DS 0D WORKSIZE EQU *-WORKAREA *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK END -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Tuesday, October 29, 2019 3:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN So according to: "20 The routine_name contains only blanks and the routine_entry was zero. The PreInit table was not updated." https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/ceeam141.htm Joe On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman wrote: > The listing has the SYSSTATE set AMODE 64 The LISTPSW indicates > botH the EA and BA BITS of the PSW as one indicating AMODE 64 at > location F8 right before the call CELQPIPI > > > CEEWQPIP: LOADing CELQPIPI > CEEWQPIP: Doing CELQPIPI INIT_MAIN > IKJ57024I AT +F6 > TEST > istpsw > IKJ57652I PSW LOCATED AT 8BA068 > XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR > 01118 1101 00 00 1 1 1F7010F6 > > TEST > t +f8 > TEST > o > CEEWQLOD: Called to LOAD "TEST64A " > IKJ57024I AT +F8 > TEST > > The program is AMODE 64 > > TEST64A0D30 0001D6 0064 > ANY > > This is a listing of the table > +CEEXPTBL DCCL8'CELQPTBL'Eyecatcher > + DCA(CELQPIT0058) Number of e > + DCF'16'Entry size > + DCF'100' Version > ice routines > > Source Statement HLASM R6 > + DCAL1(0) > + DC3X'00' >CELQPITY TEST64A,0 ically load CE > + DCCL8'TEST64A' Name, set t > + DCAD(0)Load dblwd >CELQPITS , End of CELQPIP > +CELQPIT0058 EQU 1 Number of e > * > Here is the listing of TEST64A > > TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > YREGS > *LOAD EP=CEETEST > *LRR15,R0 > *BASR R14,R15 > CELQCALL opendata,(SYSADATA),WORKREG=10 > XR R15,R15 > CELQEPLG > SYSADATA DC CL8'SYSADATA' > *CEEPDDA opendata,SCOPE=IMPORT > PARM1DC A(COMMANDS) > PARM2DC A(FEEDBACK) > > Here is the link > For TEST64A > > //* > //* LINK EDIT THE PROGRAM * > //* > //STEP0200 EXEC PGM=IEWL,COND=(0,LT,STEP0100), > // PARM='AMODE(64),LIST,MAP,XREF,CASE=MIXED,DYNAM=DLL' > //SYSPRINT DD SYSOUT=* > //SYSDEFSD DD SYSOUT=* > //OBJ DD DSN=&,DISP=(OLD,PASS) > //SYSLIB DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB > // DD DISP=SHR,DSN=CEE.SCEEBND2 > // DD DISP=SHR,DSN=CEE.SCEELKED > //SYSLMOD DD
Re: CPACF for TN3270 encryption
"We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses TLS 1.2 via IBM’s policy agent" All its workload goes to CPACF ? On Tue, 29 Oct, 2019, 1:42 PM Michael Babcock, wrote: > We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses > TLS 1.2 via IBM’s policy agent. > > On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson > wrote: > > > Hi > > > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > > > Just trying to understand its functionality and has anyone tried this > > functionality implementated for TN3270 connectivity. > > > > Jake > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > Michael Babcock > OneMain Financial > z/OS Systems Programmer, Lead > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
I guess I could do a series of calls to the exports things is they all share a global area Thanks On Oct 29, 2019, at 8:47 AM, David Crayford wrote: > > Why do you need a DLL? Can you just use PIPI to call a static program? > >> On 2019-10-29 8:15 PM, Joseph Reichman wrote: >> This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s a good >> idea to try to use add_entry >> After init_sub/MAIN >> This is the program I trying to initiate as in Assembler LE 64 bit prolog >> CELQPRLG does not have a main and I cannot call a 64 C DLL I was thinking >> CELQPIPI would resolve these issues >> >> Thanks >> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A >> YREGS >> *LOAD EP=CEETEST >> *LRR15,R0 >> *BASR R14,R15 >> CELQCALL opendata,(SYSADATA),WORKREG=10 >> XR R15,R15 >> CELQEPLG >> SYSADATA DC CL8'SYSADATA' >> *CEEPDDA opendata,SCOPE=IMPORT >> PARM1DC A(COMMANDS) >> PARM2DC A(FEEDBACK) >> DS 0H >> DC H'9' >> COMMANDS DC C'AT ENTRY ' >> FEEDBACK DS CL12 >> CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA >> CEECAA MAPPING OF THE COMMON ANCHOR AREA >> *LLPPA CEEPPA >> WORKAREA DSECT >> DS 0D >> WORKSIZE EQU *-WORKAREA >> *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK >> END >> >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Joe Monk >> Sent: Tuesday, October 29, 2019 3:34 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN >> >> So according to: >> >> "20 The routine_name contains only blanks and the routine_entry was zero. >> The PreInit table was not updated." >> >> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/ceeam141.htm >> >> Joe >> >> On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman >> wrote: >> >>> The listing has the SYSSTATE set AMODE 64 The LISTPSW indicates >>> botH the EA and BA BITS of the PSW as one indicating AMODE 64 at >>> location F8 right before the call CELQPIPI >>> >>> >>> CEEWQPIP: LOADing CELQPIPI >>> CEEWQPIP: Doing CELQPIPI INIT_MAIN >>> IKJ57024I AT +F6 >>> TEST >>> istpsw >>> IKJ57652I PSW LOCATED AT 8BA068 >>> XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR >>> 01118 1101 00 00 1 1 1F7010F6 >>> >>> TEST >>> t +f8 >>> TEST >>> o >>> CEEWQLOD: Called to LOAD "TEST64A " >>> IKJ57024I AT +F8 >>> TEST >>> >>> The program is AMODE 64 >>> >>> TEST64A0D30 0001D6 0064 >>> ANY >>> >>> This is a listing of the table >>> +CEEXPTBL DCCL8'CELQPTBL'Eyecatcher >>> + DCA(CELQPIT0058) Number of e >>> + DCF'16'Entry size >>> + DCF'100' Version >>> ice routines >>> >>> Source Statement HLASM R6 >>> + DCAL1(0) >>> + DC3X'00' >>>CELQPITY TEST64A,0 ically load CE >>> + DCCL8'TEST64A' Name, set t >>> + DCAD(0)Load dblwd >>>CELQPITS , End of CELQPIP >>> +CELQPIT0058 EQU 1 Number of e >>> * >>> Here is the listing of TEST64A >>> >>> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A >>> YREGS >>> *LOAD EP=CEETEST >>> *LRR15,R0 >>> *BASR R14,R15 >>> CELQCALL opendata,(SYSADATA),WORKREG=10 >>> XR R15,R15 >>> CELQEPLG >>> SYSADATA DC CL8'SYSADATA' >>> *CEEPDDA opendata,SCOPE=IMPORT >>> PARM1DC A(COMMANDS) >>> PARM2DC A(FEEDBACK) >>> >>> Here is the link >>> For TEST64A >>> >>> //* >>> //* LINK EDIT THE PROGRAM * >>> //* >>> //STEP0200 EXEC PGM=IEWL,COND=(0,LT,STEP0100), >>> // PARM='AMODE(64),LIST,MAP,XREF,CASE=MIXED,DYNAM=DLL' >>> //SYSPRINT DD SYSOUT=* >>> //SYSDEFSD DD SYSOUT=* >>> //OBJ DD DSN=&,DISP=(OLD,PASS) >>> //SYSLIB DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB >>> // DD DISP=SHR,DSN=CEE.SCEEBND2 >>> // DD DISP=SHR,DSN=CEE.SCEELKED >>> //SYSLMOD DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB >>> //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,2)),DSN= >>> //SYSPRINT DD SYSOUT=*,DCB=(RECFM=FB,BLKSIZE=3509) >>> //SYSLIN DD * >>> IMPORT CODE64,'SYSADATA','opendata' >>> INCLUDE OBJ(TEST64A) >>> ENTRY TEST64A >>> NAME TEST64A(R) >>> >>> >>> >>> >>> >>> 84 * >>>
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
I am trying to call a AMODE 64 bit C DLL (exported function) from assembler and because CELQPRLG (LE 64 bit prologue) doesn't support main like CEEENTRY (MAIN=YES) Cannt seem do it I thought the INIT_MAIN function for CELQPIPI would do the trick for me Thanks -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Tuesday, October 29, 2019 9:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN Joe: What are you trying to accomplish exactly so we can better assist you ? Scott On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman wrote: > I guess I could do a series of calls to the exports things is they all > share a global area > > Thanks > > > On Oct 29, 2019, at 8:47 AM, David Crayford wrote: > > > > Why do you need a DLL? Can you just use PIPI to call a static program? > > > >> On 2019-10-29 8:15 PM, Joseph Reichman wrote: > >> This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s > >> a > good idea to try to use add_entry > >> After init_sub/MAIN > >> This is the program I trying to initiate as in Assembler LE 64 bit > prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I > was thinking CELQPIPI would resolve these issues > >> > >> Thanks > >> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > >> YREGS > >> *LOAD EP=CEETEST > >> *LRR15,R0 > >> *BASR R14,R15 > >> CELQCALL opendata,(SYSADATA),WORKREG=10 > >> XR R15,R15 > >> CELQEPLG > >> SYSADATA DC CL8'SYSADATA' > >> *CEEPDDA opendata,SCOPE=IMPORT > >> PARM1DC A(COMMANDS) > >> PARM2DC A(FEEDBACK) > >> DS 0H > >> DC H'9' > >> COMMANDS DC C'AT ENTRY ' > >> FEEDBACK DS CL12 > >> CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA > >> CEECAA MAPPING OF THE COMMON ANCHOR AREA > >> *LLPPA CEEPPA > >> WORKAREA DSECT > >> DS 0D > >> WORKSIZE EQU *-WORKAREA > >> *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK > >> END > > >> > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf Of Joe Monk > >> Sent: Tuesday, October 29, 2019 3:34 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > >> > >> So according to: > >> > >> "20 The routine_name contains only blanks and the routine_entry was > zero. > >> The PreInit table was not updated." > >> > >> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v > 2r1.ceeam00/ceeam141.htm > >> > >> Joe > >> > >> On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman > >> > >> wrote: > >> > >>> The listing has the SYSSTATE set AMODE 64 The LISTPSW indicates > >>> botH the EA and BA BITS of the PSW as one indicating AMODE 64 at > >>> location F8 right before the call CELQPIPI > >>> > >>> > >>> CEEWQPIP: LOADing CELQPIPI > >>> CEEWQPIP: Doing CELQPIPI INIT_MAIN IKJ57024I AT +F6 TEST istpsw > >>> IKJ57652I PSW LOCATED AT 8BA068 > >>> XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR > >>> 01118 1101 00 00 1 1 1F7010F6 > >>> > >>> TEST > >>> t +f8 > >>> TEST > >>> o > >>> CEEWQLOD: Called to LOAD "TEST64A " > >>> IKJ57024I AT +F8 > >>> TEST > >>> > >>> The program is AMODE 64 > >>> > >>> TEST64A0D30 0001D6 00 > 64 > >>> ANY > >>> > >>> This is a listing of the table > >>> +CEEXPTBL DCCL8'CELQPTBL'Eyecatcher > >>> + DCA(CELQPIT0058) Number of e > >>> + DCF'16'Entry size > >>> + DCF'100' Version > >>> ice routines > >>> > >>> Source Statement HLASM R6 > >>> + DCAL1(0) > >>> + DC3X'00' > >>>CELQPITY TEST64A,0 ically load CE > >>> + DCCL8'TEST64A' Name, set t > >>> + DCAD(0)Load dblwd > >>>CELQPITS , End of CELQPIP > >>> +CELQPIT0058 EQU 1 Number of e > >>> * > >>> Here is the listing of TEST64A > >>> > >>> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > >>> YREGS > >>> *LOAD EP=CEETEST > >>> *LRR15,R0 > >>> *BASR R14,R15 > >>> CELQCALL opendata,(SYSADATA),WORKREG=10 > >>> XR R15,R15 > >>> CELQEPLG > >>> SYSADATA DC CL8'SYSADATA' > >>> *CEEPDDA opendata,SCOPE=IMPORT > >>> PARM1DC A(COMMANDS) > >>> PARM2DC A(FEEDBACK) > >>> > >>> Here is the link > >>> For TEST64A > >>> > >>> //* > >>> //* LINK EDIT THE PROGRAM * > >>> // > >>> * > >>> //STEP0200
Re: DCOLLECT use of KB/MB
OK, I don't follow; in particular, what do you mean by "jump"? In case it helps clarify, I am SORTing a DCOLLECT file, which for some reason, uses "kilobytes" for normal DASD, and "megabytes" for EAV. I came up with an INREC statement that fixes that, but I'd like to use the correct multiplier (I assume 1024 for now): SORT FIELDS=(DCVDVTYP,A,DCVDVNUM,A) INREC IFTHEN=(WHEN=(DCVEAVOL,EQ,X'80'), OVERLAY=(49:DCVVLCAP,MUL,+1024,TO=FI,LENGTH=4)) re 'MVS': funny. re IBM-MAIN search: I got a list of message title & authors, the newest being from 2008. Nothing on the list was clickable, so it would be useless even if weren't already useless. sas On Mon, Oct 28, 2019 at 10:23 PM Mike Schwab wrote: > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idai200/dcxmp1.htm > > http://publibz.boulder.ibm.com/epubs/pdf/dgt3i201.pdf > > Appendix F DCollect output > Record Type V VOLUME Printed page 478+ PDF page 504+. > > Offset 121 x'79' is x'80' when EAV and capacity is stated in MB, Is > x'00' when non-EAV and capacity is stated in KB. > Offset 36 (free), 40 (allocated), 44 (total) is 4 bytes binary > capacity. Non-EAV about 56 (KB) is one track and it uses the exact > byte count from the capacity table then divides and will jump. So > dividing by 56 will cause jumps and suggest adding 1 before dividing > for a report in number of tracks. > > On Mon, Oct 28, 2019 at 8:32 PM Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > > On Mon, 28 Oct 2019 16:22:34 -0500, Mike Schwab wrote: > > > > >Power of 2. Number of cylinders is another field. > > > > > Citation needed. > > > > >On Mon, Oct 28, 2019 at 4:12 PM Steve Smith wrote: > > >> > > >> What does "kilobytes" and "megabytes" mean to DCOLLECT, > specifically, type > > >> "V" (volume) records in the values it shows for volume capacity, and > > >> several related fields? i.e. does KB=1000 or KB=1024? After spending > > >> considerable time perusing the fine manual, I haven't seen a hint. > > >> > > >> btw, my attempt to search the list on > https://listserv.ua.edu/cgi-bin/wa > > >> returned nothing for any term I tried (including 'MVS'). > > >> > > That's 1,048,576 VSes. > > > > -- gil > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
Joe: What are you trying to accomplish exactly so we can better assist you ? Scott On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman wrote: > I guess I could do a series of calls to the exports things is they all > share a global area > > Thanks > > > On Oct 29, 2019, at 8:47 AM, David Crayford wrote: > > > > Why do you need a DLL? Can you just use PIPI to call a static program? > > > >> On 2019-10-29 8:15 PM, Joseph Reichman wrote: > >> This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s a > good idea to try to use add_entry > >> After init_sub/MAIN > >> This is the program I trying to initiate as in Assembler LE 64 bit > prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I was > thinking CELQPIPI would resolve these issues > >> > >> Thanks > >> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > >> YREGS > >> *LOAD EP=CEETEST > >> *LRR15,R0 > >> *BASR R14,R15 > >> CELQCALL opendata,(SYSADATA),WORKREG=10 > >> XR R15,R15 > >> CELQEPLG > >> SYSADATA DC CL8'SYSADATA' > >> *CEEPDDA opendata,SCOPE=IMPORT > >> PARM1DC A(COMMANDS) > >> PARM2DC A(FEEDBACK) > >> DS 0H > >> DC H'9' > >> COMMANDS DC C'AT ENTRY ' > >> FEEDBACK DS CL12 > >> CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA > >> CEECAA MAPPING OF THE COMMON ANCHOR AREA > >> *LLPPA CEEPPA > >> WORKAREA DSECT > >> DS 0D > >> WORKSIZE EQU *-WORKAREA > >> *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK > >> END > > >> > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf Of Joe Monk > >> Sent: Tuesday, October 29, 2019 3:34 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > >> > >> So according to: > >> > >> "20 The routine_name contains only blanks and the routine_entry was > zero. > >> The PreInit table was not updated." > >> > >> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/ceeam141.htm > >> > >> Joe > >> > >> On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman > >> wrote: > >> > >>> The listing has the SYSSTATE set AMODE 64 The LISTPSW indicates > >>> botH the EA and BA BITS of the PSW as one indicating AMODE 64 at > >>> location F8 right before the call CELQPIPI > >>> > >>> > >>> CEEWQPIP: LOADing CELQPIPI > >>> CEEWQPIP: Doing CELQPIPI INIT_MAIN > >>> IKJ57024I AT +F6 > >>> TEST > >>> istpsw > >>> IKJ57652I PSW LOCATED AT 8BA068 > >>> XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR > >>> 01118 1101 00 00 1 1 1F7010F6 > >>> > >>> TEST > >>> t +f8 > >>> TEST > >>> o > >>> CEEWQLOD: Called to LOAD "TEST64A " > >>> IKJ57024I AT +F8 > >>> TEST > >>> > >>> The program is AMODE 64 > >>> > >>> TEST64A0D30 0001D6 00 > 64 > >>> ANY > >>> > >>> This is a listing of the table > >>> +CEEXPTBL DCCL8'CELQPTBL'Eyecatcher > >>> + DCA(CELQPIT0058) Number of e > >>> + DCF'16'Entry size > >>> + DCF'100' Version > >>> ice routines > >>> > >>> Source Statement HLASM R6 > >>> + DCAL1(0) > >>> + DC3X'00' > >>>CELQPITY TEST64A,0 ically load CE > >>> + DCCL8'TEST64A' Name, set t > >>> + DCAD(0)Load dblwd > >>>CELQPITS , End of CELQPIP > >>> +CELQPIT0058 EQU 1 Number of e > >>> * > >>> Here is the listing of TEST64A > >>> > >>> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > >>> YREGS > >>> *LOAD EP=CEETEST > >>> *LRR15,R0 > >>> *BASR R14,R15 > >>> CELQCALL opendata,(SYSADATA),WORKREG=10 > >>> XR R15,R15 > >>> CELQEPLG > >>> SYSADATA DC CL8'SYSADATA' > >>> *CEEPDDA opendata,SCOPE=IMPORT > >>> PARM1DC A(COMMANDS) > >>> PARM2DC A(FEEDBACK) > >>> > >>> Here is the link > >>> For TEST64A > >>> > >>> //* > >>> //* LINK EDIT THE PROGRAM * > >>> //* > >>> //STEP0200 EXEC PGM=IEWL,COND=(0,LT,STEP0100), > >>> // PARM='AMODE(64),LIST,MAP,XREF,CASE=MIXED,DYNAM=DLL' > >>> //SYSPRINT DD SYSOUT=* > >>> //SYSDEFSD DD SYSOUT=* > >>> //OBJ DD DSN=&,DISP=(OLD,PASS) > >>> //SYSLIB DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB > >>> // DD DISP=SHR,DSN=CEE.SCEEBND2 > >>> // DD DISP=SHR,DSN=CEE.SCEELKED > >>> //SYSLMOD DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB > >>> //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,2)),DSN= > >>> //SYSPRINT DD
Re: Best way for a task to give up the CPU and let other tasks run?
On Wed, 23 Oct 2019 18:23:31 +, Seymour J Metz wrote: >The Dispatcher has been using timers for decades. What interrupts your >code is an external event from a timer or from a SIGP on another CPU. >If you're running with appropriate goals, don't try to second guess WLM. I believe the OP mentioned he received complaints that his task was hogging the CPU. WLM does not cover every situation. I'm guessing that changing the WLM goals did not solve the problem since that would be the first thing most people consider when this situation occurs. The most obvious situation is with multiple active TCB's in an address space because WLM does not directly deal with TCB priority. I think the op should look at the CHAP macro and implementing WLM enclaves. CHAP would be simpler but I suspect that enclaves will probably be the more appropriate solution. CALLDISP probably won't be necessary but that really depends upon the situation. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
Jake Anderson asked: >Is it possible to encrypt TN3270 connectivity using CPACF ? And then later added: >We got this feature along with our z14 so wanted to make use of this and am >not sure if PAGENT traffic can be offloaded to zIIP Just to be clear: CPACF is crypto in the chip (much like Intel AES-NI), has nothing to do with zIIP. Not clear whether you were thinking they were related. As Radoslaw noted, it can be hard to tell where encryption is happening, but my expectation would be that whatever is doing your TN3270 encryption would use CPACF if available. If it's not, it's pretty primitive; CPACF has been around at least a decade, things really should be using it by now. .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Can I INIT_MAIN a 64 bit CELQPRLG program to call 64 bit C DLL export
In light of the recent posts Would anybody know if I can use INIT_MAIN using CELQPIPI to initialize a 64 bit CELQPRLG assembler which calls a 64 bit C DLL export Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCOLLECT use of KB/MB
Jump in volume size. I wrote a program on a non-EAV sysplex that divided the capacity KB by 849.960 to get the number of cylinders. Had an off by 1 error at various sizes, so I added 1 to round up before dividing. On Tue, Oct 29, 2019 at 7:56 AM Steve Smith wrote: > > OK, I don't follow; in particular, what do you mean by "jump"? > > In case it helps clarify, I am SORTing a DCOLLECT file, which for some > reason, uses "kilobytes" for normal DASD, and "megabytes" for EAV. I came > up with an INREC statement that fixes that, but I'd like to use the correct > multiplier (I assume 1024 for now): > > SORT FIELDS=(DCVDVTYP,A,DCVDVNUM,A) > INREC IFTHEN=(WHEN=(DCVEAVOL,EQ,X'80'), >OVERLAY=(49:DCVVLCAP,MUL,+1024,TO=FI,LENGTH=4)) > > re 'MVS': funny. > > re IBM-MAIN search: I got a list of message title & authors, the newest > being from 2008. Nothing on the list was clickable, so it would be useless > even if weren't already useless. > > sas > > > On Mon, Oct 28, 2019 at 10:23 PM Mike Schwab > wrote: > > > > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idai200/dcxmp1.htm > > > > http://publibz.boulder.ibm.com/epubs/pdf/dgt3i201.pdf > > > > Appendix F DCollect output > > Record Type V VOLUME Printed page 478+ PDF page 504+. > > > > Offset 121 x'79' is x'80' when EAV and capacity is stated in MB, Is > > x'00' when non-EAV and capacity is stated in KB. > > Offset 36 (free), 40 (allocated), 44 (total) is 4 bytes binary > > capacity. Non-EAV about 56 (KB) is one track and it uses the exact > > byte count from the capacity table then divides and will jump. So > > dividing by 56 will cause jumps and suggest adding 1 before dividing > > for a report in number of tracks. > > > > On Mon, Oct 28, 2019 at 8:32 PM Paul Gilmartin > > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > On Mon, 28 Oct 2019 16:22:34 -0500, Mike Schwab wrote: > > > > > > >Power of 2. Number of cylinders is another field. > > > > > > > Citation needed. > > > > > > >On Mon, Oct 28, 2019 at 4:12 PM Steve Smith wrote: > > > >> > > > >> What does "kilobytes" and "megabytes" mean to DCOLLECT, > > specifically, type > > > >> "V" (volume) records in the values it shows for volume capacity, and > > > >> several related fields? i.e. does KB=1000 or KB=1024? After spending > > > >> considerable time perusing the fine manual, I haven't seen a hint. > > > >> > > > >> btw, my attempt to search the list on > > https://listserv.ua.edu/cgi-bin/wa > > > >> returned nothing for any term I tried (including 'MVS'). > > > >> > > > That's 1,048,576 VSes. > > > > > > -- gil > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > Mike A Schwab, Springfield IL USA > > Where do Forest Rangers go to get away from it all? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > sas > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
Thanks Joe Reichman 170-10 73 rd ave Fresh meadows NY 11366 > On Oct 29, 2019, at 1:02 PM, scott Ford wrote: > > Joe, > > I have called it in Cobol . I thought there some pretty good examples in > the IBM Doc. > Let us know .. > > Scott > >> On Tue, Oct 29, 2019 at 11:50 AM Joseph Reichman >> wrote: >> >> Peter thanks so much if I need a C main then this exercise in CELQPIPI is >> irrelevant >> >> Now I need to figure out how to call a C main from non LE assembler as all >> of my code is that >> >>> On Oct 29, 2019, at 11:45 AM, Farley, Peter x23353 < >>> peter.far...@broadridge.com> wrote: >>> >>> Joe, >>> >>> From my somewhat limited experience with CEEPIPI (only to enable 31-bit >> COBOL calls from 31-bit non-LE assembler subroutines called from 31-bit >> COBOL main), it looks to me like your 64-bit assembler code needs to set up >> a CEEPIPI INIT_SUB not an INIT_MAIN since you are calling the DLL as a >> subroutine. >>> >>> You may also need to use a "stub" C main program to just call your >> assembler 64-bit code and then exit just to establish the C main >> environment, since as you found the CELQPRLG doesn't allow you to make your >> assembler code look like a 64-bit C main. >>> >>> HTH >>> >>> Peter >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >> Behalf Of Joseph Reichman >>> Sent: Tuesday, October 29, 2019 11:32 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN >>> >>> It was my understanding after a lot of digging that I couldn’t call 64 >> bit C from assembler because the 64 bit LE assembler prologue macro >> CELQPRLG doesn’t support main like CEEENTRY and there for the LE >> environment isn’t established I just thought that CELQPIPI would do that >> for assembler but am having a hard time getting that working with a 64 bit >> LE assembler Thanks >>> >>> On Oct 29, 2019, at 11:26 AM, scott Ford >> wrote: Joe, I havent dont 64bit C ..but I would be surprised the guys here on the listserv havent . I understand 64bit in theory but working as a ISV my mgmt is stuck in the Cobol back woods. Scott > On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman > > wrote: > > I am trying to call a AMODE 64 bit C DLL (exported function) from > assembler and because CELQPRLG (LE 64 bit prologue) doesn't support > main like CEEENTRY (MAIN=YES) Cannt seem do it I thought the > INIT_MAIN function for CELQPIPI would do the trick for me > > Thanks > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of scott Ford > Sent: Tuesday, October 29, 2019 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > > Joe: > > What are you trying to accomplish exactly so we can better assist you ? > Scott > > On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman > > wrote: > >> I guess I could do a series of calls to the exports things is they >> all share a global area >> >> Thanks >> >> >> On Oct 29, 2019, at 8:47 AM, David Crayford >> wrote: >>> >>> Why do you need a DLL? Can you just use PIPI to call a static >> program? >>> On 2019-10-29 8:15 PM, Joseph Reichman wrote: This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s a >> good idea to try to use add_entry After init_sub/MAIN This is the program I trying to initiate as in Assembler LE 64 bit >> prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I >> was thinking CELQPIPI would resolve these issues Thanks TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A YREGS *LOAD EP=CEETEST *LRR15,R0 *BASR R14,R15 CELQCALL opendata,(SYSADATA),WORKREG=10 XR R15,R15 CELQEPLG SYSADATA DC CL8'SYSADATA' *CEEPDDA opendata,SCOPE=IMPORT PARM1DC A(COMMANDS) PARM2DC A(FEEDBACK) DS 0H DC H'9' COMMANDS DC C'AT ENTRY ' FEEDBACK DS CL12 CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA CEECAA MAPPING OF THE COMMON ANCHOR AREA *LLPPA CEEPPA WORKAREA DSECT DS 0D WORKSIZE EQU *-WORKAREA *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK END >> -Original Message- From: IBM Mainframe Discussion List On >> Behalf Of Joe Monk Sent: Tuesday, October 29, 2019 3:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
On 2019-10-29 11:50 PM, Joseph Reichman wrote: Peter thanks so much if I need a C main then this exercise in CELQPIPI is irrelevant We use CEEPIPI and don't use main. We use subroutines with the following (this is C++ code) #pragma linkage(FUWIPSTR, fetchable) // required for PIPI init_sub/call_sub Now I need to figure out how to call a C main from non LE assembler as all of my code is that On Oct 29, 2019, at 11:45 AM, Farley, Peter x23353 wrote: Joe, From my somewhat limited experience with CEEPIPI (only to enable 31-bit COBOL calls from 31-bit non-LE assembler subroutines called from 31-bit COBOL main), it looks to me like your 64-bit assembler code needs to set up a CEEPIPI INIT_SUB not an INIT_MAIN since you are calling the DLL as a subroutine. You may also need to use a "stub" C main program to just call your assembler 64-bit code and then exit just to establish the C main environment, since as you found the CELQPRLG doesn't allow you to make your assembler code look like a 64-bit C main. HTH Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Tuesday, October 29, 2019 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN It was my understanding after a lot of digging that I couldn’t call 64 bit C from assembler because the 64 bit LE assembler prologue macro CELQPRLG doesn’t support main like CEEENTRY and there for the LE environment isn’t established I just thought that CELQPIPI would do that for assembler but am having a hard time getting that working with a 64 bit LE assembler Thanks On Oct 29, 2019, at 11:26 AM, scott Ford wrote: Joe, I havent dont 64bit C ..but I would be surprised the guys here on the listserv havent . I understand 64bit in theory but working as a ISV my mgmt is stuck in the Cobol back woods. Scott On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman wrote: I am trying to call a AMODE 64 bit C DLL (exported function) from assembler and because CELQPRLG (LE 64 bit prologue) doesn't support main like CEEENTRY (MAIN=YES) Cannt seem do it I thought the INIT_MAIN function for CELQPIPI would do the trick for me Thanks -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Tuesday, October 29, 2019 9:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN Joe: What are you trying to accomplish exactly so we can better assist you ? Scott On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman wrote: I guess I could do a series of calls to the exports things is they all share a global area Thanks On Oct 29, 2019, at 8:47 AM, David Crayford wrote: Why do you need a DLL? Can you just use PIPI to call a static program? On 2019-10-29 8:15 PM, Joseph Reichman wrote: This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s a good idea to try to use add_entry After init_sub/MAIN This is the program I trying to initiate as in Assembler LE 64 bit prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I was thinking CELQPIPI would resolve these issues Thanks TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A YREGS *LOAD EP=CEETEST *LRR15,R0 *BASR R14,R15 CELQCALL opendata,(SYSADATA),WORKREG=10 XR R15,R15 CELQEPLG SYSADATA DC CL8'SYSADATA' *CEEPDDA opendata,SCOPE=IMPORT PARM1DC A(COMMANDS) PARM2DC A(FEEDBACK) DS 0H DC H'9' COMMANDS DC C'AT ENTRY ' FEEDBACK DS CL12 CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA CEECAA MAPPING OF THE COMMON ANCHOR AREA *LLPPA CEEPPA WORKAREA DSECT DS 0D WORKSIZE EQU *-WORKAREA *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK END -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Tuesday, October 29, 2019 3:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN So according to: "20 The routine_name contains only blanks and the routine_entry was zero. The PreInit table was not updated." https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos .v 2r1.ceeam00/ceeam141.htm Joe On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman wrote: The listing has the SYSSTATE set AMODE 64 The LISTPSW indicates botH the EA and BA BITS of the PSW as one indicating AMODE 64 at location F8 right before the call CELQPIPI CEEWQPIP: LOADing CELQPIPI CEEWQPIP: Doing CELQPIPI INIT_MAIN IKJ57024I AT +F6 TEST istpsw IKJ57652I PSW LOCATED AT 8BA068 XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR 01118 1101 00 00 1 1 1F7010F6 TEST t +f8 TEST o CEEWQLOD: Called to LOAD "TEST64A " IKJ57024I AT +F8 TEST The program is AMODE 64 TEST64A0D30 0001D6
Re: DCOLLECT use of KB/MB
There are two archives. You search the old one. On Tue, Oct 29, 2019 at 7:56 AM Steve Smith wrote: > > OK, I don't follow; in particular, what do you mean by "jump"? > > In case it helps clarify, I am SORTing a DCOLLECT file, which for some > reason, uses "kilobytes" for normal DASD, and "megabytes" for EAV. I came > up with an INREC statement that fixes that, but I'd like to use the correct > multiplier (I assume 1024 for now): > > SORT FIELDS=(DCVDVTYP,A,DCVDVNUM,A) > INREC IFTHEN=(WHEN=(DCVEAVOL,EQ,X'80'), >OVERLAY=(49:DCVVLCAP,MUL,+1024,TO=FI,LENGTH=4)) > > re 'MVS': funny. > > re IBM-MAIN search: I got a list of message title & authors, the newest > being from 2008. Nothing on the list was clickable, so it would be useless > even if weren't already useless. > > sas > > > On Mon, Oct 28, 2019 at 10:23 PM Mike Schwab > wrote: > > > > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idai200/dcxmp1.htm > > > > http://publibz.boulder.ibm.com/epubs/pdf/dgt3i201.pdf > > > > Appendix F DCollect output > > Record Type V VOLUME Printed page 478+ PDF page 504+. > > > > Offset 121 x'79' is x'80' when EAV and capacity is stated in MB, Is > > x'00' when non-EAV and capacity is stated in KB. > > Offset 36 (free), 40 (allocated), 44 (total) is 4 bytes binary > > capacity. Non-EAV about 56 (KB) is one track and it uses the exact > > byte count from the capacity table then divides and will jump. So > > dividing by 56 will cause jumps and suggest adding 1 before dividing > > for a report in number of tracks. > > > > On Mon, Oct 28, 2019 at 8:32 PM Paul Gilmartin > > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > On Mon, 28 Oct 2019 16:22:34 -0500, Mike Schwab wrote: > > > > > > >Power of 2. Number of cylinders is another field. > > > > > > > Citation needed. > > > > > > >On Mon, Oct 28, 2019 at 4:12 PM Steve Smith wrote: > > > >> > > > >> What does "kilobytes" and "megabytes" mean to DCOLLECT, > > specifically, type > > > >> "V" (volume) records in the values it shows for volume capacity, and > > > >> several related fields? i.e. does KB=1000 or KB=1024? After spending > > > >> considerable time perusing the fine manual, I haven't seen a hint. > > > >> > > > >> btw, my attempt to search the list on > > https://listserv.ua.edu/cgi-bin/wa > > > >> returned nothing for any term I tried (including 'MVS'). > > > >> > > > That's 1,048,576 VSes. > > > > > > -- gil > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > Mike A Schwab, Springfield IL USA > > Where do Forest Rangers go to get away from it all? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > sas > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
We got this feature along with our z14 so wanted to make use of this and am not sure if PAGENT traffic can be offloaded to zIIP On Tue, 29 Oct, 2019, 9:26 PM R.S., wrote: > Michael, > It's not so easy. > You use encrypted communication. That's what you know. > However you don't know what hardware is used for enciphering/deciphering > data. > I'm rather sure that it is NOT CryptoExpress card (let's omit > handshaking). Note, CPACF is not CryptoExpress. You can have CPACF and > no CryptoExpress cards. You cannot have CryptoExpress cards without > CPACF, but this is not interesting in this case. > However sometimes it is not worth to use crypto hardware for very small > data blocks. Like in terminal communication. In such case it can be > software algorithm, which means CPU cycles. Or not, because AFAIK it can > be offloaded to zIIP. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2019-10-29 o 10:47, Michael Babcock pisze: > > I can’t say I’m 100% sure but highly suspect it does. We don’t have our > > crypto express cards configured yet so I know it’s not using them. > > > > On Tue, Oct 29, 2019 at 4:44 AM Jake Anderson > > wrote: > > > >> "We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic > uses > >> TLS 1.2 via IBM’s policy agent" > >> > >> All its workload goes to CPACF ? > >> > >> On Tue, 29 Oct, 2019, 1:42 PM Michael Babcock, > >> wrote: > >> > >>> We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic > uses > >>> TLS 1.2 via IBM’s policy agent. > >>> > >>> On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson < > justmainfra...@gmail.com> > >>> wrote: > >>> > Hi > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > Just trying to understand its functionality and has anyone tried this > functionality implementated for TN3270 connectivity. > > Jake > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2019 r. wynosi 169.347.928 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.347.928 as at 1 January 2019. > > -- > 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: Return code X'20' 32 from CELQPIPI INIT_MAIN
Peter thanks so much if I need a C main then this exercise in CELQPIPI is irrelevant Now I need to figure out how to call a C main from non LE assembler as all of my code is that On Oct 29, 2019, at 11:45 AM, Farley, Peter x23353 wrote: > > Joe, > > From my somewhat limited experience with CEEPIPI (only to enable 31-bit COBOL > calls from 31-bit non-LE assembler subroutines called from 31-bit COBOL > main), it looks to me like your 64-bit assembler code needs to set up a > CEEPIPI INIT_SUB not an INIT_MAIN since you are calling the DLL as a > subroutine. > > You may also need to use a "stub" C main program to just call your assembler > 64-bit code and then exit just to establish the C main environment, since as > you found the CELQPRLG doesn't allow you to make your assembler code look > like a 64-bit C main. > > HTH > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Tuesday, October 29, 2019 11:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > > It was my understanding after a lot of digging that I couldn’t call 64 bit C > from assembler because the 64 bit LE assembler prologue macro CELQPRLG > doesn’t support main like CEEENTRY and there for the LE environment isn’t > established I just thought that CELQPIPI would do that for assembler but am > having a hard time getting that working with a 64 bit LE assembler Thanks > > On Oct 29, 2019, at 11:26 AM, scott Ford >> wrote: >> >> Joe, >> >> I havent dont 64bit C ..but I would be surprised the guys here on the >> listserv havent . >> I understand 64bit in theory but working as a ISV my mgmt is stuck in >> the Cobol back woods. >> >> Scott >> >>> On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman >>> >>> wrote: >>> >>> I am trying to call a AMODE 64 bit C DLL (exported function) from >>> assembler and because CELQPRLG (LE 64 bit prologue) doesn't support >>> main like CEEENTRY (MAIN=YES) Cannt seem do it I thought the >>> INIT_MAIN function for CELQPIPI would do the trick for me >>> >>> Thanks >>> >>> >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of scott Ford >>> Sent: Tuesday, October 29, 2019 9:35 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN >>> >>> Joe: >>> >>> What are you trying to accomplish exactly so we can better assist you ? >>> Scott >>> >>> On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman >>> >>> wrote: >>> I guess I could do a series of calls to the exports things is they all share a global area Thanks On Oct 29, 2019, at 8:47 AM, David Crayford wrote: > > Why do you need a DLL? Can you just use PIPI to call a static program? > >> On 2019-10-29 8:15 PM, Joseph Reichman wrote: >> This is add_entry I was using INIT_SUB, INIT_MAIN regardless >> that’s a good idea to try to use add_entry >> After init_sub/MAIN >> This is the program I trying to initiate as in Assembler LE 64 bit prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I was thinking CELQPIPI would resolve these issues >> >> Thanks >> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A >>YREGS >> *LOAD EP=CEETEST >> *LRR15,R0 >> *BASR R14,R15 >>CELQCALL opendata,(SYSADATA),WORKREG=10 >>XR R15,R15 >>CELQEPLG >> SYSADATA DC CL8'SYSADATA' >> *CEEPDDA opendata,SCOPE=IMPORT >> PARM1DC A(COMMANDS) >> PARM2DC A(FEEDBACK) >> DS 0H >>DC H'9' >> COMMANDS DC C'AT ENTRY ' >> FEEDBACK DS CL12 >>CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA >>CEECAA MAPPING OF THE COMMON ANCHOR AREA >> *LLPPA CEEPPA >> WORKAREA DSECT >>DS 0D >> WORKSIZE EQU *-WORKAREA >> *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK >>END >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of Joe Monk >> Sent: Tuesday, October 29, 2019 3:34 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN >> >> So according to: >> >> "20 The routine_name contains only blanks and the routine_entry >> was zero. >> The PreInit table was not updated." >> >> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos .v 2r1.ceeam00/ceeam141.htm >> >> Joe >> >> On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman >> >> wrote: >> >>> The listing has the SYSSTATE set AMODE 64 The LISTPSW >>> indicates botH the EA and BA BITS of the PSW as one
Re: DCOLLECT use of KB/MB
OK, after I found my old 3390 reference card, and doing the math, I proved that DCOLLECT is indeed using 2**10 to mean kilo- (and presumably 2**20 for mega-). I found a 3390-3 (I think) with 3,339 cylinders, and multiplied by 849,960 (bytes/cyl) and got 2838016440, which /1024 = 2771500.4296875. DCOLLECT shows 2,771,500. QED. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
Joe, I have called it in Cobol . I thought there some pretty good examples in the IBM Doc. Let us know .. Scott On Tue, Oct 29, 2019 at 11:50 AM Joseph Reichman wrote: > Peter thanks so much if I need a C main then this exercise in CELQPIPI is > irrelevant > > Now I need to figure out how to call a C main from non LE assembler as all > of my code is that > > On Oct 29, 2019, at 11:45 AM, Farley, Peter x23353 < > peter.far...@broadridge.com> wrote: > > > > Joe, > > > > From my somewhat limited experience with CEEPIPI (only to enable 31-bit > COBOL calls from 31-bit non-LE assembler subroutines called from 31-bit > COBOL main), it looks to me like your 64-bit assembler code needs to set up > a CEEPIPI INIT_SUB not an INIT_MAIN since you are calling the DLL as a > subroutine. > > > > You may also need to use a "stub" C main program to just call your > assembler 64-bit code and then exit just to establish the C main > environment, since as you found the CELQPRLG doesn't allow you to make your > assembler code look like a 64-bit C main. > > > > HTH > > > > Peter > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > > Sent: Tuesday, October 29, 2019 11:32 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > > > > It was my understanding after a lot of digging that I couldn’t call 64 > bit C from assembler because the 64 bit LE assembler prologue macro > CELQPRLG doesn’t support main like CEEENTRY and there for the LE > environment isn’t established I just thought that CELQPIPI would do that > for assembler but am having a hard time getting that working with a 64 bit > LE assembler Thanks > > > > On Oct 29, 2019, at 11:26 AM, scott Ford > > >> wrote: > >> > >> Joe, > >> > >> I havent dont 64bit C ..but I would be surprised the guys here on the > >> listserv havent . > >> I understand 64bit in theory but working as a ISV my mgmt is stuck in > >> the Cobol back woods. > >> > >> Scott > >> > >>> On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman > >>> > >>> wrote: > >>> > >>> I am trying to call a AMODE 64 bit C DLL (exported function) from > >>> assembler and because CELQPRLG (LE 64 bit prologue) doesn't support > >>> main like CEEENTRY (MAIN=YES) Cannt seem do it I thought the > >>> INIT_MAIN function for CELQPIPI would do the trick for me > >>> > >>> Thanks > >>> > >>> > >>> > >>> -Original Message- > >>> From: IBM Mainframe Discussion List On > >>> Behalf Of scott Ford > >>> Sent: Tuesday, October 29, 2019 9:35 AM > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > >>> > >>> Joe: > >>> > >>> What are you trying to accomplish exactly so we can better assist you ? > >>> Scott > >>> > >>> On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman > >>> > >>> wrote: > >>> > I guess I could do a series of calls to the exports things is they > all share a global area > > Thanks > > > On Oct 29, 2019, at 8:47 AM, David Crayford > wrote: > > > > Why do you need a DLL? Can you just use PIPI to call a static > program? > > > >> On 2019-10-29 8:15 PM, Joseph Reichman wrote: > >> This is add_entry I was using INIT_SUB, INIT_MAIN regardless > >> that’s a > good idea to try to use add_entry > >> After init_sub/MAIN > >> This is the program I trying to initiate as in Assembler LE 64 bit > prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I > was thinking CELQPIPI would resolve these issues > >> > >> Thanks > >> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > >>YREGS > >> *LOAD EP=CEETEST > >> *LRR15,R0 > >> *BASR R14,R15 > >>CELQCALL opendata,(SYSADATA),WORKREG=10 > >>XR R15,R15 > >>CELQEPLG > >> SYSADATA DC CL8'SYSADATA' > >> *CEEPDDA opendata,SCOPE=IMPORT > >> PARM1DC A(COMMANDS) > >> PARM2DC A(FEEDBACK) > >> DS 0H > >>DC H'9' > >> COMMANDS DC C'AT ENTRY ' > >> FEEDBACK DS CL12 > >>CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA > >>CEECAA MAPPING OF THE COMMON ANCHOR AREA > >> *LLPPA CEEPPA > >> WORKAREA DSECT > >>DS 0D > >> WORKSIZE EQU *-WORKAREA > >> *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK > >>END > > >> > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf Of Joe Monk > >> Sent: Tuesday, October 29, 2019 3:34 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > >> > >> So according to: > >> > >> "20 The routine_name contains only blanks and the routine_entry > >> was > zero. > >> The
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
Joe, I havent dont 64bit C ..but I would be surprised the guys here on the listserv havent . I understand 64bit in theory but working as a ISV my mgmt is stuck in the Cobol back woods. Scott On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman wrote: > I am trying to call a AMODE 64 bit C DLL (exported function) from > assembler and because CELQPRLG (LE 64 bit prologue) doesn't support main > like CEEENTRY (MAIN=YES) Cannt seem do it I thought the INIT_MAIN function > for CELQPIPI would do the trick for me > > Thanks > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of scott Ford > Sent: Tuesday, October 29, 2019 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > > Joe: > > What are you trying to accomplish exactly so we can better assist you ? > Scott > > On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman > wrote: > > > I guess I could do a series of calls to the exports things is they all > > share a global area > > > > Thanks > > > > > > On Oct 29, 2019, at 8:47 AM, David Crayford wrote: > > > > > > Why do you need a DLL? Can you just use PIPI to call a static program? > > > > > >> On 2019-10-29 8:15 PM, Joseph Reichman wrote: > > >> This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s > > >> a > > good idea to try to use add_entry > > >> After init_sub/MAIN > > >> This is the program I trying to initiate as in Assembler LE 64 bit > > prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I > > was thinking CELQPIPI would resolve these issues > > >> > > >> Thanks > > >> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > > >> YREGS > > >> *LOAD EP=CEETEST > > >> *LRR15,R0 > > >> *BASR R14,R15 > > >> CELQCALL opendata,(SYSADATA),WORKREG=10 > > >> XR R15,R15 > > >> CELQEPLG > > >> SYSADATA DC CL8'SYSADATA' > > >> *CEEPDDA opendata,SCOPE=IMPORT > > >> PARM1DC A(COMMANDS) > > >> PARM2DC A(FEEDBACK) > > >> DS 0H > > >> DC H'9' > > >> COMMANDS DC C'AT ENTRY ' > > >> FEEDBACK DS CL12 > > >> CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA > > >> CEECAA MAPPING OF THE COMMON ANCHOR AREA > > >> *LLPPA CEEPPA > > >> WORKAREA DSECT > > >> DS 0D > > >> WORKSIZE EQU *-WORKAREA > > >> *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK > > >> END > > > > >> > > >> > > >> > > >> -Original Message- > > >> From: IBM Mainframe Discussion List On > > Behalf Of Joe Monk > > >> Sent: Tuesday, October 29, 2019 3:34 AM > > >> To: IBM-MAIN@LISTSERV.UA.EDU > > >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > > >> > > >> So according to: > > >> > > >> "20 The routine_name contains only blanks and the routine_entry was > > zero. > > >> The PreInit table was not updated." > > >> > > >> > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v > > 2r1.ceeam00/ceeam141.htm > > >> > > >> Joe > > >> > > >> On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman > > >> > > >> wrote: > > >> > > >>> The listing has the SYSSTATE set AMODE 64 The LISTPSW indicates > > >>> botH the EA and BA BITS of the PSW as one indicating AMODE 64 at > > >>> location F8 right before the call CELQPIPI > > >>> > > >>> > > >>> CEEWQPIP: LOADing CELQPIPI > > >>> CEEWQPIP: Doing CELQPIPI INIT_MAIN IKJ57024I AT +F6 TEST istpsw > > >>> IKJ57652I PSW LOCATED AT 8BA068 > > >>> XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR > > >>> 01118 1101 00 00 1 1 > 1F7010F6 > > >>> > > >>> TEST > > >>> t +f8 > > >>> TEST > > >>> o > > >>> CEEWQLOD: Called to LOAD "TEST64A " > > >>> IKJ57024I AT +F8 > > >>> TEST > > >>> > > >>> The program is AMODE 64 > > >>> > > >>> TEST64A0D30 0001D6 00 > > 64 > > >>> ANY > > >>> > > >>> This is a listing of the table > > >>> +CEEXPTBL DCCL8'CELQPTBL'Eyecatcher > > >>> + DCA(CELQPIT0058) Number of e > > >>> + DCF'16'Entry size > > >>> + DCF'100' Version > > >>> ice routines > > >>> > > >>> Source Statement HLASM R6 > > >>> + DCAL1(0) > > >>> + DC3X'00' > > >>>CELQPITY TEST64A,0 ically load CE > > >>> + DCCL8'TEST64A' Name, set t > > >>> + DCAD(0)Load dblwd > > >>>CELQPITS , End of CELQPIP > > >>> +CELQPIT0058 EQU 1 Number of e > > >>> * > > >>> Here is the listing of TEST64A > > >>> > > >>> TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > > >>> YREGS > > >>> *LOAD EP=CEETEST > > >>> *LRR15,R0 > > >>> *BASR R14,R15 > > >>> CELQCALL
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
It was my understanding after a lot of digging that I couldn’t call 64 bit C from assembler because the 64 bit LE assembler prologue macro CELQPRLG doesn’t support main like CEEENTRY and there for the LE environment isn’t established I just thought that CELQPIPI would do that for assembler but am having a hard time getting that working with a 64 bit LE assembler Thanks On Oct 29, 2019, at 11:26 AM, scott Ford wrote: > > Joe, > > I havent dont 64bit C ..but I would be surprised the guys here on the > listserv havent . > I understand 64bit in theory but working as a ISV my mgmt is stuck in the > Cobol back woods. > > Scott > >> On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman >> wrote: >> >> I am trying to call a AMODE 64 bit C DLL (exported function) from >> assembler and because CELQPRLG (LE 64 bit prologue) doesn't support main >> like CEEENTRY (MAIN=YES) Cannt seem do it I thought the INIT_MAIN function >> for CELQPIPI would do the trick for me >> >> Thanks >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf >> Of scott Ford >> Sent: Tuesday, October 29, 2019 9:35 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN >> >> Joe: >> >> What are you trying to accomplish exactly so we can better assist you ? >> Scott >> >> On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman >> wrote: >> >>> I guess I could do a series of calls to the exports things is they all >>> share a global area >>> >>> Thanks >>> >>> >>> On Oct 29, 2019, at 8:47 AM, David Crayford wrote: Why do you need a DLL? Can you just use PIPI to call a static program? > On 2019-10-29 8:15 PM, Joseph Reichman wrote: > This is add_entry I was using INIT_SUB, INIT_MAIN regardless that’s > a >>> good idea to try to use add_entry > After init_sub/MAIN > This is the program I trying to initiate as in Assembler LE 64 bit >>> prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I >>> was thinking CELQPIPI would resolve these issues > > Thanks >TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > YREGS > *LOAD EP=CEETEST > *LRR15,R0 > *BASR R14,R15 > CELQCALL opendata,(SYSADATA),WORKREG=10 > XR R15,R15 > CELQEPLG > SYSADATA DC CL8'SYSADATA' > *CEEPDDA opendata,SCOPE=IMPORT > PARM1DC A(COMMANDS) > PARM2DC A(FEEDBACK) > DS 0H > DC H'9' > COMMANDS DC C'AT ENTRY ' > FEEDBACK DS CL12 > CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA > CEECAA MAPPING OF THE COMMON ANCHOR AREA > *LLPPA CEEPPA > WORKAREA DSECT > DS 0D > WORKSIZE EQU *-WORKAREA > *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK > END >>> > > > > -Original Message- > From: IBM Mainframe Discussion List On >>> Behalf Of Joe Monk > Sent: Tuesday, October 29, 2019 3:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > > So according to: > > "20 The routine_name contains only blanks and the routine_entry was >>> zero. > The PreInit table was not updated." > > >>> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v >>> 2r1.ceeam00/ceeam141.htm > > Joe > > On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman > > wrote: > >> The listing has the SYSSTATE set AMODE 64 The LISTPSW indicates >> botH the EA and BA BITS of the PSW as one indicating AMODE 64 at >> location F8 right before the call CELQPIPI >> >> >> CEEWQPIP: LOADing CELQPIPI >> CEEWQPIP: Doing CELQPIPI INIT_MAIN IKJ57024I AT +F6 TEST istpsw >> IKJ57652I PSW LOCATED AT 8BA068 >> XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR >> 01118 1101 00 00 1 1 >> 1F7010F6 >> >> TEST >> t +f8 >> TEST >> o >> CEEWQLOD: Called to LOAD "TEST64A " >> IKJ57024I AT +F8 >> TEST >> >> The program is AMODE 64 >> >> TEST64A0D30 0001D6 00 >>> 64 >> ANY >> >> This is a listing of the table >> +CEEXPTBL DCCL8'CELQPTBL'Eyecatcher >> + DCA(CELQPIT0058) Number of e >> + DCF'16'Entry size >> + DCF'100' Version >> ice routines >> >> Source Statement HLASM R6 >> + DCAL1(0) >> + DC3X'00' >> CELQPITY TEST64A,0 ically load CE >> + DCCL8'TEST64A' Name, set t >> + DCAD(0)Load dblwd
Re: DCOLLECT use of KB/MB
On Tue, 29 Oct 2019 11:58:00 -0400, Steve Smith wrote: >OK, after I found my old 3390 reference card, and doing the math, I proved >that DCOLLECT is indeed using 2**10 to mean kilo- (and presumably 2**20 for >mega-). I found a 3390-3 (I think) with 3,339 cylinders, and multiplied by >849,960 (bytes/cyl) and got 2838016440, which /1024 = 2771500.4296875. >DCOLLECT shows 2,771,500. QED. > In "Glossary of z/OS terms and abbreviations" (no title page nor part #; apparently for z/OS 2.3) I see the (somewhat garbled): megabyte (MB). 220 bytes, 1 048 576 bytes.,048,576 bytes. ??? (sic) I find no similar entry, correct or incorrect, for "kilo*". I wonder which convention IBM uses when it specifies the shipping weight of a z in kilograms? If IBM can flout SI in some cases, why not in all? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCOLLECT use of KB/MB
W dniu 2019-10-29 o 17:58, Paul Gilmartin pisze: On Tue, 29 Oct 2019 11:58:00 -0400, Steve Smith wrote: OK, after I found my old 3390 reference card, and doing the math, I proved that DCOLLECT is indeed using 2**10 to mean kilo- (and presumably 2**20 for mega-). I found a 3390-3 (I think) with 3,339 cylinders, and multiplied by 849,960 (bytes/cyl) and got 2838016440, which /1024 = 2771500.4296875. DCOLLECT shows 2,771,500. QED. In "Glossary of z/OS terms and abbreviations" (no title page nor part #; apparently for z/OS 2.3) I see the (somewhat garbled): megabyte (MB). 220 bytes, 1 048 576 bytes.,048,576 bytes. ??? (sic) I find no similar entry, correct or incorrect, for "kilo*". I wonder which convention IBM uses when it specifies the shipping weight of a z in kilograms? If IBM can flout SI in some cases, why not in all? Gil, It's quite easy. Dualism of kilo as 1000 or maybe 1024 exists only in IT world, exactly in memory (RAM, disk, etc.). So kilograms are obvoiusly clear. The same for GHz of CPU frequency. Some habit/practice say binary prefixes are for RAM (memory), while decimal are used for disks and tapes (external storage), but this is not always true. In many cases programs provides disk information using "binary" megabytes. Of course there are special prefixes for binary: KiB, MiB, GiB. Or just Ki, Mi, Gi. This is unambigous even if you want to tell us about weight - Kig = 1024 grams. Very rare, but unambigous. What remains ambigous is kB, MB, GB - memory size. You never know whether it is intentional decimal prefix, or just author ignored existence of Ki, Mi, Gi, Ti, Pi... Regarding DCOLLECT - I have no idea. :-) Regards -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
Joe, From my somewhat limited experience with CEEPIPI (only to enable 31-bit COBOL calls from 31-bit non-LE assembler subroutines called from 31-bit COBOL main), it looks to me like your 64-bit assembler code needs to set up a CEEPIPI INIT_SUB not an INIT_MAIN since you are calling the DLL as a subroutine. You may also need to use a "stub" C main program to just call your assembler 64-bit code and then exit just to establish the C main environment, since as you found the CELQPRLG doesn't allow you to make your assembler code look like a 64-bit C main. HTH Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Tuesday, October 29, 2019 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN It was my understanding after a lot of digging that I couldn’t call 64 bit C from assembler because the 64 bit LE assembler prologue macro CELQPRLG doesn’t support main like CEEENTRY and there for the LE environment isn’t established I just thought that CELQPIPI would do that for assembler but am having a hard time getting that working with a 64 bit LE assembler Thanks On Oct 29, 2019, at 11:26 AM, scott Ford wrote: > > Joe, > > I havent dont 64bit C ..but I would be surprised the guys here on the > listserv havent . > I understand 64bit in theory but working as a ISV my mgmt is stuck in > the Cobol back woods. > > Scott > >> On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman >> >> wrote: >> >> I am trying to call a AMODE 64 bit C DLL (exported function) from >> assembler and because CELQPRLG (LE 64 bit prologue) doesn't support >> main like CEEENTRY (MAIN=YES) Cannt seem do it I thought the >> INIT_MAIN function for CELQPIPI would do the trick for me >> >> Thanks >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of scott Ford >> Sent: Tuesday, October 29, 2019 9:35 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN >> >> Joe: >> >> What are you trying to accomplish exactly so we can better assist you ? >> Scott >> >> On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman >> >> wrote: >> >>> I guess I could do a series of calls to the exports things is they >>> all share a global area >>> >>> Thanks >>> >>> >>> On Oct 29, 2019, at 8:47 AM, David Crayford wrote: Why do you need a DLL? Can you just use PIPI to call a static program? > On 2019-10-29 8:15 PM, Joseph Reichman wrote: > This is add_entry I was using INIT_SUB, INIT_MAIN regardless > that’s a >>> good idea to try to use add_entry > After init_sub/MAIN > This is the program I trying to initiate as in Assembler LE 64 bit >>> prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I >>> was thinking CELQPIPI would resolve these issues > > Thanks >TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > YREGS > *LOAD EP=CEETEST > *LRR15,R0 > *BASR R14,R15 > CELQCALL opendata,(SYSADATA),WORKREG=10 > XR R15,R15 > CELQEPLG > SYSADATA DC CL8'SYSADATA' > *CEEPDDA opendata,SCOPE=IMPORT > PARM1DC A(COMMANDS) > PARM2DC A(FEEDBACK) > DS 0H > DC H'9' > COMMANDS DC C'AT ENTRY ' > FEEDBACK DS CL12 > CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA > CEECAA MAPPING OF THE COMMON ANCHOR AREA > *LLPPA CEEPPA > WORKAREA DSECT > DS 0D > WORKSIZE EQU *-WORKAREA > *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK > END >>> > > > > -Original Message- > From: IBM Mainframe Discussion List On >>> Behalf Of Joe Monk > Sent: Tuesday, October 29, 2019 3:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > > So according to: > > "20 The routine_name contains only blanks and the routine_entry > was >>> zero. > The PreInit table was not updated." > > >>> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos >>> .v >>> 2r1.ceeam00/ceeam141.htm > > Joe > > On Mon, Oct 28, 2019 at 8:55 PM Joseph Reichman > > wrote: > >> The listing has the SYSSTATE set AMODE 64 The LISTPSW >> indicates botH the EA and BA BITS of the PSW as one indicating >> AMODE 64 at location F8 right before the call CELQPIPI >> >> >> CEEWQPIP: LOADing CELQPIPI >> CEEWQPIP: Doing CELQPIPI INIT_MAIN IKJ57024I AT +F6 TEST istpsw >> IKJ57652I PSW LOCATED AT 8BA068 >> XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR >> 01118 1101 00 00 1 1 >> 1F7010F6 >> >> TEST >> t +f8 >> TEST
Re: CPACF for TN3270 encryption
Michael, It's not so easy. You use encrypted communication. That's what you know. However you don't know what hardware is used for enciphering/deciphering data. I'm rather sure that it is NOT CryptoExpress card (let's omit handshaking). Note, CPACF is not CryptoExpress. You can have CPACF and no CryptoExpress cards. You cannot have CryptoExpress cards without CPACF, but this is not interesting in this case. However sometimes it is not worth to use crypto hardware for very small data blocks. Like in terminal communication. In such case it can be software algorithm, which means CPU cycles. Or not, because AFAIK it can be offloaded to zIIP. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-29 o 10:47, Michael Babcock pisze: I can’t say I’m 100% sure but highly suspect it does. We don’t have our crypto express cards configured yet so I know it’s not using them. On Tue, Oct 29, 2019 at 4:44 AM Jake Anderson wrote: "We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses TLS 1.2 via IBM’s policy agent" All its workload goes to CPACF ? On Tue, 29 Oct, 2019, 1:42 PM Michael Babcock, wrote: We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses TLS 1.2 via IBM’s policy agent. On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson wrote: Hi Is it possible to encrypt TN3270 connectivity using CPACF ? Just trying to understand its functionality and has anyone tried this functionality implementated for TN3270 connectivity. Jake == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Sunday, October 6, 2019, 08:14:36 PM PDT, David Crayford wrote: >On 2019-10-07 2:06 AM, Jon Perryman wrote: >> I'm saying that IBM can't fix this problem because the problem lies with >> Unix shell design. > IBM can and have fixed the problem! BPXBATCH is so bad they wrote a > replacement AOPBATCH which works just as Kirk describes. IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator. AOPBATCH simply changes the problems. IBM doesn't need to address those problems because they are outside the scope of AOP. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
Welcome back. On Tue, 29 Oct 2019 20:21:07 +, Jon Perryman wrote: > >On Sunday, October 6, 2019, 08:14:36 PM PDT, David Crayford wrote: > > >On 2019-10-07 2:06 AM, Jon Perryman wrote: > >>> I'm saying that IBM can't fix this problem because the problem lies with >>> Unix shell design. > >> IBM can and have fixed the problem! BPXBATCH is so bad they wrote a >> replacement AOPBATCH which works just as Kirk describes. > >IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for >BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe >that BPXBATCH was documented as running a Unix command but we stacked commands >by using the semicolon command separator. > >AOPBATCH simply changes the problems. IBM doesn't need to address those >problems because they are outside the scope of AOP. > Oh, my. True Blue! An often-criticized limitation of BPXBATCH is that it does not tolerate instream data sets or classic data sets as STDIN. AOPBATCH removes that limitation and introduces no new limitations (AFAIK?) Stacked commands using a semicolon separator do not allow "#" comments. Comments are widely considered a valuable aspect of coding technique. Are you arguing for a semantic distinction between "fixing a problem" and "removing an onerous limitation"? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCOLLECT use of KB/MB
No, I do not. The old one is pre-2005. Aha... specifying a "since" date of 2016-01-01 gets me up to the present. It seems there's a hard limit of 100 hits, and it starts from the oldest. sas On Tue, Oct 29, 2019 at 2:53 PM Mike Schwab wrote: > There are two archives. You search the old one. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
Yep, looking at the z/os xl c/c++ manuals there are examples of Hlasm calling C, You have to use XPLINK for 64bit and there are prologs and epilogs. Scott On Tue, Oct 29, 2019 at 2:22 PM David Crayford wrote: > On 2019-10-29 11:50 PM, Joseph Reichman wrote: > > Peter thanks so much if I need a C main then this exercise in CELQPIPI > is irrelevant > > > We use CEEPIPI and don't use main. We use subroutines with the following > (this is C++ code) > > #pragma linkage(FUWIPSTR, fetchable) // required for PIPI init_sub/call_sub > > > > > > Now I need to figure out how to call a C main from non LE assembler as > all of my code is that > > > > On Oct 29, 2019, at 11:45 AM, Farley, Peter x23353 < > peter.far...@broadridge.com> wrote: > >> Joe, > >> > >> From my somewhat limited experience with CEEPIPI (only to enable > 31-bit COBOL calls from 31-bit non-LE assembler subroutines called from > 31-bit COBOL main), it looks to me like your 64-bit assembler code needs to > set up a CEEPIPI INIT_SUB not an INIT_MAIN since you are calling the DLL as > a subroutine. > >> > >> You may also need to use a "stub" C main program to just call your > assembler 64-bit code and then exit just to establish the C main > environment, since as you found the CELQPRLG doesn't allow you to make your > assembler code look like a 64-bit C main. > >> > >> HTH > >> > >> Peter > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > >> Sent: Tuesday, October 29, 2019 11:32 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > >> > >> It was my understanding after a lot of digging that I couldn’t call 64 > bit C from assembler because the 64 bit LE assembler prologue macro > CELQPRLG doesn’t support main like CEEENTRY and there for the LE > environment isn’t established I just thought that CELQPIPI would do that > for assembler but am having a hard time getting that working with a 64 bit > LE assembler Thanks > >> > >> On Oct 29, 2019, at 11:26 AM, scott Ford >> > >>> wrote: > >>> > >>> Joe, > >>> > >>> I havent dont 64bit C ..but I would be surprised the guys here on the > >>> listserv havent . > >>> I understand 64bit in theory but working as a ISV my mgmt is stuck in > >>> the Cobol back woods. > >>> > >>> Scott > >>> > On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman > > wrote: > > I am trying to call a AMODE 64 bit C DLL (exported function) from > assembler and because CELQPRLG (LE 64 bit prologue) doesn't support > main like CEEENTRY (MAIN=YES) Cannt seem do it I thought the > INIT_MAIN function for CELQPIPI would do the trick for me > > Thanks > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of scott Ford > Sent: Tuesday, October 29, 2019 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN > > Joe: > > What are you trying to accomplish exactly so we can better assist you > ? > Scott > > On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman > > wrote: > > > I guess I could do a series of calls to the exports things is they > > all share a global area > > > > Thanks > > > > > > On Oct 29, 2019, at 8:47 AM, David Crayford > wrote: > >> Why do you need a DLL? Can you just use PIPI to call a static > program? > >> > >>> On 2019-10-29 8:15 PM, Joseph Reichman wrote: > >>> This is add_entry I was using INIT_SUB, INIT_MAIN regardless > >>> that’s a > > good idea to try to use add_entry > >>> After init_sub/MAIN > >>> This is the program I trying to initiate as in Assembler LE 64 bit > > prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I > > was thinking CELQPIPI would resolve these issues > >>> Thanks > >>>TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A > >>> YREGS > >>> *LOAD EP=CEETEST > >>> *LRR15,R0 > >>> *BASR R14,R15 > >>> CELQCALL opendata,(SYSADATA),WORKREG=10 > >>> XR R15,R15 > >>> CELQEPLG > >>> SYSADATA DC CL8'SYSADATA' > >>> *CEEPDDA opendata,SCOPE=IMPORT > >>> PARM1DC A(COMMANDS) > >>> PARM2DC A(FEEDBACK) > >>> DS 0H > >>> DC H'9' > >>> COMMANDS DC C'AT ENTRY ' > >>> FEEDBACK DS CL12 > >>> CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA > >>> CEECAA MAPPING OF THE COMMON ANCHOR AREA > >>> *LLPPA CEEPPA > >>> WORKAREA DSECT > >>> DS 0D > >>> WORKSIZE EQU *-WORKAREA > >>> *CEEEDB MAPPING OF THE ENCLAVE DATA BLOCK > >>> END > >>> > >>> > >>> -Original Message- > >>> From: IBM
Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
I think the only scenario that would work from a non LE assembler is calling a main 64 bit C which would than call the 64 C DLL Joe Reichman 170-10 73 rd ave Fresh meadows NY 11366 > On Oct 29, 2019, at 7:38 PM, scott Ford wrote: > > Yep, looking at the z/os xl c/c++ manuals there are examples of Hlasm > calling C, > You have to use XPLINK for 64bit and there are prologs and epilogs. > > Scott > >> On Tue, Oct 29, 2019 at 2:22 PM David Crayford wrote: >> >>> On 2019-10-29 11:50 PM, Joseph Reichman wrote: >>> Peter thanks so much if I need a C main then this exercise in CELQPIPI >> is irrelevant >> >> >> We use CEEPIPI and don't use main. We use subroutines with the following >> (this is C++ code) >> >> #pragma linkage(FUWIPSTR, fetchable) // required for PIPI init_sub/call_sub >> >> >>> >>> Now I need to figure out how to call a C main from non LE assembler as >> all of my code is that >>> >>> On Oct 29, 2019, at 11:45 AM, Farley, Peter x23353 < >> peter.far...@broadridge.com> wrote: Joe, From my somewhat limited experience with CEEPIPI (only to enable >> 31-bit COBOL calls from 31-bit non-LE assembler subroutines called from >> 31-bit COBOL main), it looks to me like your 64-bit assembler code needs to >> set up a CEEPIPI INIT_SUB not an INIT_MAIN since you are calling the DLL as >> a subroutine. You may also need to use a "stub" C main program to just call your >> assembler 64-bit code and then exit just to establish the C main >> environment, since as you found the CELQPRLG doesn't allow you to make your >> assembler code look like a 64-bit C main. HTH Peter -Original Message- From: IBM Mainframe Discussion List On >> Behalf Of Joseph Reichman Sent: Tuesday, October 29, 2019 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN It was my understanding after a lot of digging that I couldn’t call 64 >> bit C from assembler because the 64 bit LE assembler prologue macro >> CELQPRLG doesn’t support main like CEEENTRY and there for the LE >> environment isn’t established I just thought that CELQPIPI would do that >> for assembler but am having a hard time getting that working with a 64 bit >> LE assembler Thanks On Oct 29, 2019, at 11:26 AM, scott Ford >>> > wrote: > > Joe, > > I havent dont 64bit C ..but I would be surprised the guys here on the > listserv havent . > I understand 64bit in theory but working as a ISV my mgmt is stuck in > the Cobol back woods. > > Scott > >> On Tue, Oct 29, 2019 at 9:42 AM Joseph Reichman >> >> wrote: >> >> I am trying to call a AMODE 64 bit C DLL (exported function) from >> assembler and because CELQPRLG (LE 64 bit prologue) doesn't support >> main like CEEENTRY (MAIN=YES) Cannt seem do it I thought the >> INIT_MAIN function for CELQPIPI would do the trick for me >> >> Thanks >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of scott Ford >> Sent: Tuesday, October 29, 2019 9:35 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN >> >> Joe: >> >> What are you trying to accomplish exactly so we can better assist you >> ? >> Scott >> >> On Tue, Oct 29, 2019 at 8:52 AM Joseph Reichman >> >> wrote: >> >>> I guess I could do a series of calls to the exports things is they >>> all share a global area >>> >>> Thanks >>> >>> >>> On Oct 29, 2019, at 8:47 AM, David Crayford >> wrote: Why do you need a DLL? Can you just use PIPI to call a static >> program? > On 2019-10-29 8:15 PM, Joseph Reichman wrote: > This is add_entry I was using INIT_SUB, INIT_MAIN regardless > that’s a >>> good idea to try to use add_entry > After init_sub/MAIN > This is the program I trying to initiate as in Assembler LE 64 bit >>> prolog CELQPRLG does not have a main and I cannot call a 64 C DLL I >>> was thinking CELQPIPI would resolve these issues > Thanks > TEST64A CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A >YREGS > *LOAD EP=CEETEST > *LRR15,R0 > *BASR R14,R15 >CELQCALL opendata,(SYSADATA),WORKREG=10 >XR R15,R15 >CELQEPLG > SYSADATA DC CL8'SYSADATA' > *CEEPDDA opendata,SCOPE=IMPORT > PARM1DC A(COMMANDS) > PARM2DC A(FEEDBACK) > DS 0H >DC H'9' > COMMANDS DC C'AT ENTRY ' > FEEDBACK DS CL12 >CEEDSA SECTYPE=XPLINK PING OF THE DYNAMIC SAVE AREA >CEECAA MAPPING OF
Re: DCOLLECT use of KB/MB
There the Titles and Author are listed 50 at a time. They are non-click-able but scroll down and the Titles and phrase containing the search string are visible. These are click-able and puts you in the Listserv hierarchy of message or author. In a message dated 10/29/2019 6:41:18 PM Central Standard Time, sasd...@gmail.com writes: It seems there's a hard limit of 100 hits, and it starts from the oldest. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCOLLECT use of KB/MB
Dr. Merrill had the best roll-up I've seen, but don't remember which member it was. Maybe ANALDASD. In a message dated 10/29/2019 9:46:22 PM Central Standard Time, r.skoru...@bremultibank.com.pl writes: Regarding DCOLLECT - I have no idea. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
WTO message at the end of JCL
Hi Is there a WTO module which can write a message (highlight message) on a console based on the JCL previous condition code? We do not a product to do it and just curious if there is a one in CBTTAPE.? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can I INIT_MAIN a 64 bit CELQPRLG program to call 64 bit C DLL export
Joe, You should know the answer to your question because it is clearly documented that you can https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ceeam00/piniint.htm. This thread has been meandering on a bit. Why don't you just copy the example from the book which does an INIT_MAIN/CALL_MAIN and get back to us if you have any problems. We have used CEEPIPI extensively in our products and it's not a difficult service to use. CELQPIPI is just the 64-bit analog of CEEPIPI so you should be able to get something working in a couple of hours using the example -> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ceeam00/coreyex.htm. On 2019-10-30 2:44 AM, Joseph Reichman wrote: In light of the recent posts Would anybody know if I can use INIT_MAIN using CELQPIPI to initialize a 64 bit CELQPRLG assembler which calls a 64 bit C DLL export 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: WTO message at the end of JCL
http://planetmvs.com/freeware/dampf08.txt WTO from exit. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/iea3b6_Determining_equivalent_JCL.htm //STEPWTO EXEC PGM=WTO,COND=(0,EQ),PARM='JOB RC NON ZERO' On Tue, Oct 29, 2019 at 11:23 PM Peter wrote: > > Hi > > Is there a WTO module which can write a message (highlight message) on a > console based on the JCL previous condition code? > > We do not a product to do it and just curious if there is a one in CBTTAPE.? > > Peter > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO message at the end of JCL
The message displayed by WTO just comes up but i want it to br displayed as a RED colour message with outstanding message number to suppress by operator. On Wed, 30 Oct, 2019, 8:47 AM Mike Schwab, wrote: > http://planetmvs.com/freeware/dampf08.txt > WTO from exit. > > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/iea3b6_Determining_equivalent_JCL.htm > > //STEPWTO EXEC PGM=WTO,COND=(0,EQ),PARM='JOB RC NON ZERO' > > On Tue, Oct 29, 2019 at 11:23 PM Peter wrote: > > > > Hi > > > > Is there a WTO module which can write a message (highlight message) on a > > console based on the JCL previous condition code? > > > > We do not a product to do it and just curious if there is a one in > CBTTAPE.? > > > > Peter > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
