Re: IPCS VERBX 64bit storage
On Thu, 22 Sep 2022 13:16:07 +0100 Colin Paice wrote: :>I'm very rusty ( 15+ years since I last used this) ... but can you use :>your 31 bit code to access a symbol relating to a 31/64 bit data item? :>I only used 31 bit, but I think I used to get a block of storage from the :>dump with a 64 bit address into my buffer in 31 bit address. :>You have to use the correct ESSY block. :>I could be deluded It has been a while, but I already had am API for the 31 bit addresses and did not want to change the API. The 64bit call will certainly do 31 bit zero extended addresses, but I believe the way the data is returned is different. :>On Thu, 22 Sept 2022 at 11:55, Binyamin Dissen :>wrote: :> :>> Looking at my code: :>> :>> The 31bit access call is :>> :>> IHBOPLTX ,+ :>>(ABDPL, ..ABDPL+ :>>=A(ADPLSACC),..TYPE OF CALL: ACCESS STOR+ :>>MY_ADPLPACC),..ACCESS STORAGE PARM LIST + :>>MF=(E,PLIST) :>> L R15,ADPLSERV LOCATE IPCS SERVICE ROUTINE :>> BASR R14,R15 :>> :>> The 64bit access call is: :>> :>> IHBOPLTX ,+ :>>(ABDPL, ..ABDPL+ :>>=A(ADPLSMAP),..TYPE OF CALL: MAP SERVICE+ :>>XMSP), ..ACCESS STORAGE PARM LIST + :>>MF=(E,PLIST) :>> L R15,ADPLSERV LOCATE IPCS SERVICE ROUTINE :>> BASR R14,R15 :>> :>> Formatting the request is left as an exercise for the OP :>> :>> :>> :>> On Wed, 21 Sep 2022 15:49:21 -0500 David Janicek :>> wrote: :>> :>> :>Hi all. I am new to this list but I have searched the archives for an :>> answer to my question already without any luck. :>> :> :>> :>I am responsible for maintaining an IBM IPCS VERBX (verb exit) that :>> analyzes our application dumps and points out any inconsistencies in it. :>> We are in the process of moving some of our data above the bar (ATB) and I :>> need to update the VERBX to analyze that data. Unfortunately the IBM doc :>> has virtually nothing on how to access 64bit storage in an IPCS dump via a :>> VERBX. I searched the internet and the only clue I found was a 7 year old :>> post on this site by Don Poitras. He listed a routine in C that would :>> access 64bit (and 31bit) storage. I have tried to mimic that code in :>> assembler but I haven't gotten it to work yet. I am posting my code at the :>> end of this listing. My hope is that someone will either point out the :>> error of my ways or, instead, simply post their code that does the same :>> thing. When I attempt to access 64bit storage, I get the following :>> messages: :>> :> :>> :>Dump analysis will be incomplete. :>> :> XSSP passed by exit PLATFORM is not valid. :>> :> Equate Symbol record failed consistency check. :>> :> :>> :>Here's my code that I'm using. Thanks in advance for your time on this. :>> :> :>> :> :>> :>Access64BitBlock Entry , :>> :>* :>> :> Lmg R2,R3,0(R1) -> storage address and length to get :>> :>* :>> :> Cli WS_Es64,0 have we initialized storage yet? :>> :> Jne Access64BitBlock100 Yes->Don't do it again :>> :>* :>> :> LaR14,WS_Es64 Copy :>> :> LaR15,WS_Es64$ skeleton :>> :> LaR0,C_Es64 to :>> :> Lgr R1,R15working :>> :> Mvcl R14,R0 storage :>> :>* :>> :> Mvc WS_Es64AST,=Al2(ZZZASTCV) CPU ASID :>> :> Lgf R0,WS_SSAsidSet owning :>> :> StR0,WS_Es64AS1 asid :>> :> Mvi WS_Es64DTY,ZZZDTYU Set as area :>> :>* :>> :> Mvc WS_Xs64(WS_Xs64$),C_Xs64 copy skeleton :>> :> OiWS_Xs64PFL1,WS_Xs64BIT64 Indicate 64bit :>> :> Mvc WS_Xs64Code,=Al2(WS_Xs64Acc) set to access storage :>> :> Mvc WS_Xs64Modn,C_PlatFormVar :>> :> LaR0,WS_Es64 Link them :>> :> StR0,WS_Xs64Esr together :>> :>* :>> :> CallFunc Function=StorageObtain, + :>> :> Param=4096,
Re: IPCS VERBX 64bit storage
I'm very rusty ( 15+ years since I last used this) ... but can you use your 31 bit code to access a symbol relating to a 31/64 bit data item? I only used 31 bit, but I think I used to get a block of storage from the dump with a 64 bit address into my buffer in 31 bit address. You have to use the correct ESSY block. I could be deluded Colin On Thu, 22 Sept 2022 at 11:55, Binyamin Dissen wrote: > Looking at my code: > > The 31bit access call is > > IHBOPLTX ,+ >(ABDPL, ..ABDPL+ >=A(ADPLSACC),..TYPE OF CALL: ACCESS STOR+ >MY_ADPLPACC),..ACCESS STORAGE PARM LIST + >MF=(E,PLIST) > L R15,ADPLSERV LOCATE IPCS SERVICE ROUTINE > BASR R14,R15 > > The 64bit access call is: > > IHBOPLTX ,+ >(ABDPL, ..ABDPL+ >=A(ADPLSMAP),..TYPE OF CALL: MAP SERVICE+ >XMSP), ..ACCESS STORAGE PARM LIST + >MF=(E,PLIST) > L R15,ADPLSERV LOCATE IPCS SERVICE ROUTINE > BASR R14,R15 > > Formatting the request is left as an exercise for the OP > > > > On Wed, 21 Sep 2022 15:49:21 -0500 David Janicek > wrote: > > :>Hi all. I am new to this list but I have searched the archives for an > answer to my question already without any luck. > :> > :>I am responsible for maintaining an IBM IPCS VERBX (verb exit) that > analyzes our application dumps and points out any inconsistencies in it. > We are in the process of moving some of our data above the bar (ATB) and I > need to update the VERBX to analyze that data. Unfortunately the IBM doc > has virtually nothing on how to access 64bit storage in an IPCS dump via a > VERBX. I searched the internet and the only clue I found was a 7 year old > post on this site by Don Poitras. He listed a routine in C that would > access 64bit (and 31bit) storage. I have tried to mimic that code in > assembler but I haven't gotten it to work yet. I am posting my code at the > end of this listing. My hope is that someone will either point out the > error of my ways or, instead, simply post their code that does the same > thing. When I attempt to access 64bit storage, I get the following > messages: > :> > :>Dump analysis will be incomplete. > :> XSSP passed by exit PLATFORM is not valid. > :> Equate Symbol record failed consistency check. > :> > :>Here's my code that I'm using. Thanks in advance for your time on this. > :> > :> > :>Access64BitBlock Entry , > :>* > :> Lmg R2,R3,0(R1) -> storage address and length to get > :>* > :> Cli WS_Es64,0 have we initialized storage yet? > :> Jne Access64BitBlock100 Yes->Don't do it again > :>* > :> LaR14,WS_Es64 Copy > :> LaR15,WS_Es64$ skeleton > :> LaR0,C_Es64 to > :> Lgr R1,R15working > :> Mvcl R14,R0 storage > :>* > :> Mvc WS_Es64AST,=Al2(ZZZASTCV) CPU ASID > :> Lgf R0,WS_SSAsidSet owning > :> StR0,WS_Es64AS1 asid > :> Mvi WS_Es64DTY,ZZZDTYU Set as area > :>* > :> Mvc WS_Xs64(WS_Xs64$),C_Xs64 copy skeleton > :> OiWS_Xs64PFL1,WS_Xs64BIT64 Indicate 64bit > :> Mvc WS_Xs64Code,=Al2(WS_Xs64Acc) set to access storage > :> Mvc WS_Xs64Modn,C_PlatFormVar > :> LaR0,WS_Es64 Link them > :> StR0,WS_Xs64Esr together > :>* > :> CallFunc Function=StorageObtain, + > :> Param=4096, + > :> Mf=(E,WS_StorageObtainParms) > :> StR15,WS_Xs64Buf Save buffer address > :>* > :>Access64BitBlock100 Ds 0h > :> Stg R2,WS_Es64LAD Set address to obtain > :> Stg R3,WS_Es64DLE Set length to obtain > :>* > :> Sam31 , This call requires 31 bit amode > :> SysState Amode64=NO > :>* > :> LgR4,WS_Abdpl@-> IPCS parameter area > :> Using Abdpl,R4 > :>* > :> L R15,AdplServ-> IPCS Service Routine > :> Call (15), go get the reque
Re: IPCS VERBX 64bit storage
Looking at my code: The 31bit access call is IHBOPLTX ,+ (ABDPL, ..ABDPL+ =A(ADPLSACC),..TYPE OF CALL: ACCESS STOR+ MY_ADPLPACC),..ACCESS STORAGE PARM LIST + MF=(E,PLIST) L R15,ADPLSERV LOCATE IPCS SERVICE ROUTINE BASR R14,R15 The 64bit access call is: IHBOPLTX ,+ (ABDPL, ..ABDPL+ =A(ADPLSMAP),..TYPE OF CALL: MAP SERVICE+ XMSP), ..ACCESS STORAGE PARM LIST + MF=(E,PLIST) L R15,ADPLSERV LOCATE IPCS SERVICE ROUTINE BASR R14,R15 Formatting the request is left as an exercise for the OP On Wed, 21 Sep 2022 15:49:21 -0500 David Janicek wrote: :>Hi all. I am new to this list but I have searched the archives for an answer to my question already without any luck. :> :>I am responsible for maintaining an IBM IPCS VERBX (verb exit) that analyzes our application dumps and points out any inconsistencies in it. We are in the process of moving some of our data above the bar (ATB) and I need to update the VERBX to analyze that data. Unfortunately the IBM doc has virtually nothing on how to access 64bit storage in an IPCS dump via a VERBX. I searched the internet and the only clue I found was a 7 year old post on this site by Don Poitras. He listed a routine in C that would access 64bit (and 31bit) storage. I have tried to mimic that code in assembler but I haven't gotten it to work yet. I am posting my code at the end of this listing. My hope is that someone will either point out the error of my ways or, instead, simply post their code that does the same thing. When I attempt to access 64bit storage, I get the following messages: :> :>Dump analysis will be incomplete. :> XSSP passed by exit PLATFORM is not valid. :> Equate Symbol record failed consistency check. :> :>Here's my code that I'm using. Thanks in advance for your time on this. :> :> :>Access64BitBlock Entry , :>* :> Lmg R2,R3,0(R1) -> storage address and length to get :>* :> Cli WS_Es64,0 have we initialized storage yet? :> Jne Access64BitBlock100 Yes->Don't do it again :>* :> LaR14,WS_Es64 Copy :> LaR15,WS_Es64$ skeleton :> LaR0,C_Es64 to :> Lgr R1,R15working :> Mvcl R14,R0 storage :>* :> Mvc WS_Es64AST,=Al2(ZZZASTCV) CPU ASID :> Lgf R0,WS_SSAsidSet owning :> StR0,WS_Es64AS1 asid :> Mvi WS_Es64DTY,ZZZDTYU Set as area :>* :> Mvc WS_Xs64(WS_Xs64$),C_Xs64 copy skeleton :> OiWS_Xs64PFL1,WS_Xs64BIT64 Indicate 64bit :> Mvc WS_Xs64Code,=Al2(WS_Xs64Acc) set to access storage :> Mvc WS_Xs64Modn,C_PlatFormVar :> LaR0,WS_Es64 Link them :> StR0,WS_Xs64Esr together :>* :> CallFunc Function=StorageObtain, + :> Param=4096, + :> Mf=(E,WS_StorageObtainParms) :> StR15,WS_Xs64Buf Save buffer address :>* :>Access64BitBlock100 Ds 0h
Re: IPCS VERBX 64bit storage
https://www.ibm.com/docs/en/zos/2.2.0?topic=dialog-examining-64-bit-dump-data-sets On Wed, Sep 21, 2022 at 3:59 PM David Janicek wrote: > > Hi all. I am new to this list but I have searched the archives for an answer > to my question already without any luck. > > I am responsible for maintaining an IBM IPCS VERBX (verb exit) that analyzes > our application dumps and points out any inconsistencies in it. We are in > the process of moving some of our data above the bar (ATB) and I need to > update the VERBX to analyze that data. Unfortunately the IBM doc has > virtually nothing on how to access 64bit storage in an IPCS dump via a VERBX. > I searched the internet and the only clue I found was a 7 year old post on > this site by Don Poitras. He listed a routine in C that would access 64bit > (and 31bit) storage. I have tried to mimic that code in assembler but I > haven't gotten it to work yet. I am posting my code at the end of this > listing. My hope is that someone will either point out the error of my ways > or, instead, simply post their code that does the same thing. When I attempt > to access 64bit storage, I get the following messages: > > Dump analysis will be incomplete. > XSSP passed by exit PLATFORM is not valid. > Equate Symbol record failed consistency check. > > Here's my code that I'm using. Thanks in advance for your time on this. > > > Access64BitBlock Entry , > * > Lmg R2,R3,0(R1) -> storage address and length to get > * > Cli WS_Es64,0 have we initialized storage yet? > Jne Access64BitBlock100 Yes->Don't do it again > * > LaR14,WS_Es64 Copy > LaR15,WS_Es64$ skeleton > LaR0,C_Es64 to > Lgr R1,R15working > Mvcl R14,R0 storage > * > Mvc WS_Es64AST,=Al2(ZZZASTCV) CPU ASID > Lgf R0,WS_SSAsidSet owning > StR0,WS_Es64AS1 asid > Mvi WS_Es64DTY,ZZZDTYU Set as area > * > Mvc WS_Xs64(WS_Xs64$),C_Xs64 copy skeleton > OiWS_Xs64PFL1,WS_Xs64BIT64 Indicate 64bit > Mvc WS_Xs64Code,=Al2(WS_Xs64Acc) set to access storage > Mvc WS_Xs64Modn,C_PlatFormVar > LaR0,WS_Es64 Link them > StR0,WS_Xs64Esr together > * > CallFunc Function=StorageObtain, + >Param=4096, + >Mf=(E,WS_StorageObtainParms) > StR15,WS_Xs64Buf Save buffer address > * > Access64BitBlock100 Ds 0h > Stg R2,WS_Es64LAD Set address to obtain > Stg R3,WS_Es64DLE Set length to obtain > * > Sam31 , This call requires 31 bit amode > SysState Amode64=NO > * > LgR4,WS_Abdpl@-> IPCS parameter area > Using Abdpl,R4 > * > L R15,AdplServ-> IPCS Service Routine > Call (15), go get the requested storage+ >(Abdpl,=A(AdplSSym),WS_Xs64), + >Mf=(E,WS_P64Parms) > * > Sam64 , Get back in 64bit mode > SysState Amode64=YES > Drop R4 > * > Ltr R15,R15 Did it work? > Llgt R15,WS_Xs64Buf -> returned storage > JzAccess64BitBlockContinue if successful > Sgr R15,R15 Indicate storage not found > Access64BitBlock900 Ds 0h > * > Exit , > * > C_Es64 BlsrEssy Dsect=NO,ABITS=64 > C_Xs64 BlsrXssp Dsect=NO > * > BeginWS , > * > SysState Amode64=NO > WS_P64Parms Call ,(,,),Mf=L > SysState Amode64=YES > * > WS_Es64 BlsrEssy Dsect=NO,ABITS=64 > WS_Es64$ Equ *-WS_Es64 > WS_Xs64 BlsrXssp Dsect=NO > WS_Xs64$ Equ *-WS_Xs64 > * > EndWS , > > -- > 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: IPCS VERBX 64bit storage
https://listserv.ua.edu/cgi-bin/wa?A2=ind2111=IBM-MAIN=R28794=O14039FAB4B2233B763=d10jhm1%40us.ibm.com Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Janicek Sent: Wednesday, September 21, 2022 4:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IPCS VERBX 64bit storage Hi all. I am new to this list but I have searched the archives for an answer to my question already without any luck. I am responsible for maintaining an IBM IPCS VERBX (verb exit) that analyzes our application dumps and points out any inconsistencies in it. We are in the process of moving some of our data above the bar (ATB) and I need to update the VERBX to analyze that data. Unfortunately the IBM doc has virtually nothing on how to access 64bit storage in an IPCS dump via a VERBX. I searched the internet and the only clue I found was a 7 year old post on this site by Don Poitras. He listed a routine in C that would access 64bit (and 31bit) storage. I have tried to mimic that code in assembler but I haven't gotten it to work yet. I am posting my code at the end of this listing. My hope is that someone will either point out the error of my ways or, instead, simply post their code that does the same thing. When I attempt to access 64bit storage, I get the following messages: Dump analysis will be incomplete. XSSP passed by exit PLATFORM is not valid. Equate Symbol record failed consistency check. Here's my code that I'm using. Thanks in advance for your time on this. -- 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
IPCS VERBX 64bit storage
Hi all. I am new to this list but I have searched the archives for an answer to my question already without any luck. I am responsible for maintaining an IBM IPCS VERBX (verb exit) that analyzes our application dumps and points out any inconsistencies in it. We are in the process of moving some of our data above the bar (ATB) and I need to update the VERBX to analyze that data. Unfortunately the IBM doc has virtually nothing on how to access 64bit storage in an IPCS dump via a VERBX. I searched the internet and the only clue I found was a 7 year old post on this site by Don Poitras. He listed a routine in C that would access 64bit (and 31bit) storage. I have tried to mimic that code in assembler but I haven't gotten it to work yet. I am posting my code at the end of this listing. My hope is that someone will either point out the error of my ways or, instead, simply post their code that does the same thing. When I attempt to access 64bit storage, I get the following messages: Dump analysis will be incomplete. XSSP passed by exit PLATFORM is not valid. Equate Symbol record failed consistency check. Here's my code that I'm using. Thanks in advance for your time on this. Access64BitBlock Entry , * Lmg R2,R3,0(R1) -> storage address and length to get * Cli WS_Es64,0 have we initialized storage yet? Jne Access64BitBlock100 Yes->Don't do it again * LaR14,WS_Es64 Copy LaR15,WS_Es64$ skeleton LaR0,C_Es64 to Lgr R1,R15working Mvcl R14,R0 storage * Mvc WS_Es64AST,=Al2(ZZZASTCV) CPU ASID Lgf R0,WS_SSAsidSet owning StR0,WS_Es64AS1 asid Mvi WS_Es64DTY,ZZZDTYU Set as area * Mvc WS_Xs64(WS_Xs64$),C_Xs64 copy skeleton OiWS_Xs64PFL1,WS_Xs64BIT64 Indicate 64bit Mvc WS_Xs64Code,=Al2(WS_Xs64Acc) set to access storage Mvc WS_Xs64Modn,C_PlatFormVar LaR0,WS_Es64 Link them StR0,WS_Xs64Esr together * CallFunc Function=StorageObtain, + Param=4096, + Mf=(E,WS_StorageObtainParms) StR15,WS_Xs64Buf Save buffer address * Access64BitBlock100 Ds 0h Stg R2,WS_Es64LAD Set address to obtain Stg R3,WS_Es64DLE Set length to obtain * Sam31 , This call requires 31 bit amode SysState Amode64=NO * LgR4,WS_Abdpl@-> IPCS parameter area Using Abdpl,R4 * L R15,AdplServ-> IPCS Service Routine Call (15), go get the requested storage+ (Abdpl,=A(AdplSSym),WS_Xs64), + Mf=(E,WS_P64Parms) * Sam64 , Get back in 64bit mode SysState Amode64=YES Drop R4 * Ltr R15,R15 Did it work? Llgt R15,WS_Xs64Buf -> returned storage
Re: COBOL 64bit
Because we went to IAM to solve these problems months ago. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 18, 2018, at 5:33 PM, David W Noon > <013a910fd252-dmarc-requ...@listserv.ua.edu> wrote: > > On Thu, 18 Oct 2018 15:01:33 -0400, Steve Thompson (ste...@copper.net) > wrote about "Re: COBOL 64bit" (in > ): > > [snip] >> Assume that this data set is a VSAM KSDS. And assume that we do random >> access of the records, and that those records contain pricing and rules >> for same. > > Why not use a big LSR pool for that dataset? That should speed up random > processing a treat and not use anywhere near as much memory as a full > dataset load. The BLSR subsystem is just the ticket for situations like > that. > -- > Regards, > > Dave [RLU #314465] > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > david.w.n...@googlemail.com (David W Noon) > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
Because the I/Os and I/O delays are such that loading it into a large table with key lookup in storage and the move to the buffer are done at the speed of light while the actual I/Os are done at the speed of sound. So we can get a 12hr long job (elapsed time) done in about 12% of the time. (Ok, so it is a bit slower than light). Now, if this is demand by mobile devices, we can get the info in less time than it takes to schedule the SSCHs for index and data reads. Thereby improving service using less CPU. Again, what the need is is incredibly similar to the exchange (C/O for a telco) billing process PacBell ran into circa 1992. They were able to load their billing table into a data space and cut their time to process their records from, IIRC, from ~ 30 days to about 12 hrs. You don’t want to know what the DB2 times were. So, yes they were using KSDS before going to data space and using Access Registers w/ ALC programs to get to their table entries. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 18, 2018, at 4:33 PM, Frank Swarbrick > wrote: > > Why do you want to load a KSDS in to storage instead of just doing random > access on the file? Or am I misunderstanding? > > From: IBM Mainframe Discussion List on behalf of > Steve Thompson > Sent: Thursday, October 18, 2018 1:01 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 64bit > > We have run into a situation, quite recently, where we would love > to have COBOL 6.2 to be doing 64bit storage because we need to > load a large table (actually, we want to load a data set into > storage). > > Assume that this data set is a VSAM KSDS. And assume that we do > random access of the records, and that those records contain > pricing and rules for same. > > [Shades of PacBell circa 1992 when they had to load into a data > space and use access registers to get the CO-CO billing table in > memory] > > The only way there is to write ALC code to effect a local/same > address space, data base using ATB storage and have the COBOL > code get to it by calling the ALC code that handles it all. > > Then it was pointed out that this also needed to be done in the > CICS address spaces. > > IBM missed the boat with ESA and COBOL back then, and now, I > think they are missing the boat with COBOL NOT being able to > provide large storage spaces. > > This is yet another example of some processing style/type that we > have been doing with our mainframes and just like Client Server, > and Parallel Sysplex (Ok, Geographically Diverse Sysplex), some > marketing person came up with the name of what we (customers) > have been doing. > > Is it possible to get them to catch up with their customers this > time? > > Regards, > Steve Thompson > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
On Thu, 18 Oct 2018 15:01:33 -0400, Steve Thompson (ste...@copper.net) wrote about "Re: COBOL 64bit" (in ): [snip] > Assume that this data set is a VSAM KSDS. And assume that we do random > access of the records, and that those records contain pricing and rules > for same. Why not use a big LSR pool for that dataset? That should speed up random processing a treat and not use anywhere near as much memory as a full dataset load. The BLSR subsystem is just the ticket for situations like that. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
Why do you want to load a KSDS in to storage instead of just doing random access on the file? Or am I misunderstanding? From: IBM Mainframe Discussion List on behalf of Steve Thompson Sent: Thursday, October 18, 2018 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit We have run into a situation, quite recently, where we would love to have COBOL 6.2 to be doing 64bit storage because we need to load a large table (actually, we want to load a data set into storage). Assume that this data set is a VSAM KSDS. And assume that we do random access of the records, and that those records contain pricing and rules for same. [Shades of PacBell circa 1992 when they had to load into a data space and use access registers to get the CO-CO billing table in memory] The only way there is to write ALC code to effect a local/same address space, data base using ATB storage and have the COBOL code get to it by calling the ALC code that handles it all. Then it was pointed out that this also needed to be done in the CICS address spaces. IBM missed the boat with ESA and COBOL back then, and now, I think they are missing the boat with COBOL NOT being able to provide large storage spaces. This is yet another example of some processing style/type that we have been doing with our mainframes and just like Client Server, and Parallel Sysplex (Ok, Geographically Diverse Sysplex), some marketing person came up with the name of what we (customers) have been doing. Is it possible to get them to catch up with their customers this time? Regards, Steve Thompson -- 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
AW: Re: COBOL 64bit
+1 -- Peter Hunkeler Von: "Farley, Peter x23353" An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: COBOL 64bit Datum: 17.10.18, 23:29 The following is just my personal $0.02USD worth. I speak for myself only and not for my employer. Just like any other new version of the COBOL compiler, 64-bit addressing support must be able to be phased in, subroutine by subroutine. Forcing all subroutines in a main program to become 64-bit if any one of them becomes 64-bit is NOT acceptable. Neither is any serious performance impact acceptable in mixed 64-bit-plus-31-bit programs, no matter what the starting addressing mode may be. In other words, do NOT use XPLINK for 64-bit COBOL. Find a better way that is far more compatible with current static and dynamic calling conventions. For one specific example, many (if not most) large z/OS shops have shop-wide application subroutines for I/O processing of application-specific files which all or at least many different applications in the shop use when they need to access those files. If one application program needs or desires to be recompiled for 64-bit support, there is no way that the application-specific shop-wide subroutine can be allowed to be recompiled as 64-bit because then every other application in the shop would all have to be converted to 64-bit at the same time. That can't (and won't) happen. Keeping separate libraries and separately-compiled versions for 64-bit and 31-bit subroutines may seem like a solution, but it is a management and SDLC maintenance nightmare. COBOL V5+ forced shops to support PDSE libraries for production application executables, but forking that into new separate libraries for 31-bit and 64-bit is just not practical or feasible. Every application would then have to test and maintain 2 versions of every common subroutine that they own, and there are no resources available to support that level of work. Most of us are already running as fast as we can to stay in one place, with no time to spare for anything else. Piecemeal, phased recompilation must be supported, without any serious performance penalties for either the newly compiled 64-bit programs or for the remaining 31-bit programs that are used in the same main program. It is acceptable for all-64-bit programs to have "better" performance (FSVO "better"), but impacting current SLA's because one subroutine became 64-bit is NOT acceptable. SLA's are already far too tight with no slack available. IBM must not screw this up with impossible-to-implement-in-the-real-world conditions or performance penalties. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra Sent: Wednesday, October 17, 2018 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit EXTERNAL EMAIL It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-bit modules was not possible (i.e., you would have to recompile all modules in an application), would that be interesting? Or is it the case that it is vital to be able to selectively compile modules (in 64-bit mode) and mix and match? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
We have run into a situation, quite recently, where we would love to have COBOL 6.2 to be doing 64bit storage because we need to load a large table (actually, we want to load a data set into storage). Assume that this data set is a VSAM KSDS. And assume that we do random access of the records, and that those records contain pricing and rules for same. [Shades of PacBell circa 1992 when they had to load into a data space and use access registers to get the CO-CO billing table in memory] The only way there is to write ALC code to effect a local/same address space, data base using ATB storage and have the COBOL code get to it by calling the ALC code that handles it all. Then it was pointed out that this also needed to be done in the CICS address spaces. IBM missed the boat with ESA and COBOL back then, and now, I think they are missing the boat with COBOL NOT being able to provide large storage spaces. This is yet another example of some processing style/type that we have been doing with our mainframes and just like Client Server, and Parallel Sysplex (Ok, Geographically Diverse Sysplex), some marketing person came up with the name of what we (customers) have been doing. Is it possible to get them to catch up with their customers this time? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
Thanks for your comments and additions to the requirements for a good 64-bit COBOL implementation. My opinions about multiple versions are based on financial industry audit requirements - NOTHING gets into production without testing. Period. Hence a dual-compile (and that would be two separate compiles, as I seriously doubt that one compile step can or will ever produce two different object outputs) and dual binds becomes very burdensome for the development organization when you add in the required testing. And the testing for shop-wide common subroutines is even more burdensome for a dual-compile implementation. In that case every application that uses the common modules has to be tested. We don't use IMS, only DB2, but obviously if mixed 31/64-bit calling is not permitted (or imposes severe performance penalties) both systems would require 64-bit interfaces along with the corresponding LE dynamic call interface. Not to mention the non-IBM database systems available from various ISV's (ADABAS, IDMS, etc.). Like you, we make extensive standardized use of dynamic CALL, and would also not look favorably on a DLL requirement. The developer training required to permit conversion to DLL-style linkage would prohibit that path. AFAIK there aren't many (any?) mainframe COBOL developers trained and experienced in creating or using COBOL DLL's. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Thursday, October 18, 2018 1:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit Related to this, we would require a 64-bit IMS DL/I interface and 64-bit CICS LE application support before even considering a migration to 64-bit. Well, I suppose we could leave the CICS programs 31-bit, but without IMS support for 64-bit modules it would be pretty much useless, as almost all of our core data is in IMS. From: IBM Mainframe Discussion List on behalf of Frank Swarbrick Sent: Thursday, October 18, 2018 11:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit While I understand what you are saying, and mostly agree with it, I'm not sure I agree that having 31-bit and 64-bit versions of callable subroutines is a deal breaker. It seems to me that if the compiler could generate both 31-bit and 64-bit objects from the same compile step, and the shop could then just have two program binder steps going to two different libraries. Would there be double the testing? Maybe at first until you get comfortable with the process, but after that I don't see why you'd need to test both versions to the same degree. Maybe just a "smoke test" on the version you don't plan on using for the full test, but that's about it. That being said, there probably would be an initial "cost" of recompiling and testing all sub-routines as 64-bit. I imagine, if 31/64 calls are not allowed, you'd want to have a JOBLIB/STEPLIB that contains only 31-bit modules for 31-bit run units and 64-bit modules for 64-bit run units. My personal biggest concern, regardless of whether or not there can be combined 31/64 bit run units, is if there ends up being some sort of requirement for DLL calls. We use dynamic calls exclusively for COBOL to COBOL, and while I am a fan of DLLs in theory I'd be wary of a lot of source code changes being required to "migrate" to DLL calls. Just one person's thoughts... Frank From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Wednesday, October 17, 2018 3:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit The following is just my personal $0.02USD worth. I speak for myself only and not for my employer. Just like any other new version of the COBOL compiler, 64-bit addressing support must be able to be phased in, subroutine by subroutine. Forcing all subroutines in a main program to become 64-bit if any one of them becomes 64-bit is NOT acceptable. Neither is any serious performance impact acceptable in mixed 64-bit-plus-31-bit programs, no matter what the starting addressing mode may be. In other words, do NOT use XPLINK for 64-bit COBOL. Find a better way that is far more compatible with current static and dynamic calling conventions. For one specific example, many (if not most) large z/OS shops have shop-wide application subroutines for I/O processing of application-specific files which all or at least many different applications in the shop use when they need to access those files. If one application program needs or desires to be recompiled for 64-bit support, there is no way that the application-specific shop-wide subroutine can be allowed to be recompiled as 64-bit because then every other application in the shop would all have to be converted to 64-bit at the same time. That can't (and won't) happen. Keeping separate lib
Re: COBOL 64bit
Related to this, we would require a 64-bit IMS DL/I interface and 64-bit CICS LE application support before even considering a migration to 64-bit. Well, I suppose we could leave the CICS programs 31-bit, but without IMS support for 64-bit modules it would be pretty much useless, as almost all of our core data is in IMS. From: IBM Mainframe Discussion List on behalf of Frank Swarbrick Sent: Thursday, October 18, 2018 11:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit While I understand what you are saying, and mostly agree with it, I'm not sure I agree that having 31-bit and 64-bit versions of callable subroutines is a deal breaker. It seems to me that if the compiler could generate both 31-bit and 64-bit objects from the same compile step, and the shop could then just have two program binder steps going to two different libraries. Would there be double the testing? Maybe at first until you get comfortable with the process, but after that I don't see why you'd need to test both versions to the same degree. Maybe just a "smoke test" on the version you don't plan on using for the full test, but that's about it. That being said, there probably would be an initial "cost" of recompiling and testing all sub-routines as 64-bit. I imagine, if 31/64 calls are not allowed, you'd want to have a JOBLIB/STEPLIB that contains only 31-bit modules for 31-bit run units and 64-bit modules for 64-bit run units. My personal biggest concern, regardless of whether or not there can be combined 31/64 bit run units, is if there ends up being some sort of requirement for DLL calls. We use dynamic calls exclusively for COBOL to COBOL, and while I am a fan of DLLs in theory I'd be wary of a lot of source code changes being required to "migrate" to DLL calls. Just one person's thoughts... Frank From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Wednesday, October 17, 2018 3:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit The following is just my personal $0.02USD worth. I speak for myself only and not for my employer. Just like any other new version of the COBOL compiler, 64-bit addressing support must be able to be phased in, subroutine by subroutine. Forcing all subroutines in a main program to become 64-bit if any one of them becomes 64-bit is NOT acceptable. Neither is any serious performance impact acceptable in mixed 64-bit-plus-31-bit programs, no matter what the starting addressing mode may be. In other words, do NOT use XPLINK for 64-bit COBOL. Find a better way that is far more compatible with current static and dynamic calling conventions. For one specific example, many (if not most) large z/OS shops have shop-wide application subroutines for I/O processing of application-specific files which all or at least many different applications in the shop use when they need to access those files. If one application program needs or desires to be recompiled for 64-bit support, there is no way that the application-specific shop-wide subroutine can be allowed to be recompiled as 64-bit because then every other application in the shop would all have to be converted to 64-bit at the same time. That can't (and won't) happen. Keeping separate libraries and separately-compiled versions for 64-bit and 31-bit subroutines may seem like a solution, but it is a management and SDLC maintenance nightmare. COBOL V5+ forced shops to support PDSE libraries for production application executables, but forking that into new separate libraries for 31-bit and 64-bit is just not practical or feasible. Every application would then have to test and maintain 2 versions of every common subroutine that they own, and there are no resources available to support that level of work. Most of us are already running as fast as we can to stay in one place, with no time to spare for anything else. Piecemeal, phased recompilation must be supported, without any serious performance penalties for either the newly compiled 64-bit programs or for the remaining 31-bit programs that are used in the same main program. It is acceptable for all-64-bit programs to have "better" performance (FSVO "better"), but impacting current SLA's because one subroutine became 64-bit is NOT acceptable. SLA's are already far too tight with no slack available. IBM must not screw this up with impossible-to-implement-in-the-real-world conditions or performance penalties. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra Sent: Wednesday, October 17, 2018 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit EXTERNAL EMAIL It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-
Re: COBOL 64bit
While I understand what you are saying, and mostly agree with it, I'm not sure I agree that having 31-bit and 64-bit versions of callable subroutines is a deal breaker. It seems to me that if the compiler could generate both 31-bit and 64-bit objects from the same compile step, and the shop could then just have two program binder steps going to two different libraries. Would there be double the testing? Maybe at first until you get comfortable with the process, but after that I don't see why you'd need to test both versions to the same degree. Maybe just a "smoke test" on the version you don't plan on using for the full test, but that's about it. That being said, there probably would be an initial "cost" of recompiling and testing all sub-routines as 64-bit. I imagine, if 31/64 calls are not allowed, you'd want to have a JOBLIB/STEPLIB that contains only 31-bit modules for 31-bit run units and 64-bit modules for 64-bit run units. My personal biggest concern, regardless of whether or not there can be combined 31/64 bit run units, is if there ends up being some sort of requirement for DLL calls. We use dynamic calls exclusively for COBOL to COBOL, and while I am a fan of DLLs in theory I'd be wary of a lot of source code changes being required to "migrate" to DLL calls. Just one person's thoughts... Frank From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Wednesday, October 17, 2018 3:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit The following is just my personal $0.02USD worth. I speak for myself only and not for my employer. Just like any other new version of the COBOL compiler, 64-bit addressing support must be able to be phased in, subroutine by subroutine. Forcing all subroutines in a main program to become 64-bit if any one of them becomes 64-bit is NOT acceptable. Neither is any serious performance impact acceptable in mixed 64-bit-plus-31-bit programs, no matter what the starting addressing mode may be. In other words, do NOT use XPLINK for 64-bit COBOL. Find a better way that is far more compatible with current static and dynamic calling conventions. For one specific example, many (if not most) large z/OS shops have shop-wide application subroutines for I/O processing of application-specific files which all or at least many different applications in the shop use when they need to access those files. If one application program needs or desires to be recompiled for 64-bit support, there is no way that the application-specific shop-wide subroutine can be allowed to be recompiled as 64-bit because then every other application in the shop would all have to be converted to 64-bit at the same time. That can't (and won't) happen. Keeping separate libraries and separately-compiled versions for 64-bit and 31-bit subroutines may seem like a solution, but it is a management and SDLC maintenance nightmare. COBOL V5+ forced shops to support PDSE libraries for production application executables, but forking that into new separate libraries for 31-bit and 64-bit is just not practical or feasible. Every application would then have to test and maintain 2 versions of every common subroutine that they own, and there are no resources available to support that level of work. Most of us are already running as fast as we can to stay in one place, with no time to spare for anything else. Piecemeal, phased recompilation must be supported, without any serious performance penalties for either the newly compiled 64-bit programs or for the remaining 31-bit programs that are used in the same main program. It is acceptable for all-64-bit programs to have "better" performance (FSVO "better"), but impacting current SLA's because one subroutine became 64-bit is NOT acceptable. SLA's are already far too tight with no slack available. IBM must not screw this up with impossible-to-implement-in-the-real-world conditions or performance penalties. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra Sent: Wednesday, October 17, 2018 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit EXTERNAL EMAIL It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-bit modules was not possible (i.e., you would have to recompile all modules in an application), would that be interesting? Or is it the case that it is vital to be able to selectively compile modules (in 64-bit mode) and mix and match? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby noti
Re: COBOL 64bit
No argument. The subject line was COBOL 64bit -- by implication AMODE 64 COBOL -- and so that's where my reply was coming from. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, October 18, 2018 7:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote: >And FWIW there is another overlapping complexity here besides AMODE 64 >-- speaking in theory only, because there is no reality of 64-bit COBOL. It isn't really "theory only" because it is true of assembler too. >There are really *three* kinds of module: those that are AMODE 64, >those that are AMODE 31 but use and/or count on the high halves of >registers, and those that are "pure" 31/32-bit. There are modules that use the high halves of registers and those that do not. Of those that do, some of them are AMODE(64) some of the time. Regardless of how a program uses the high halves of registers 2-12, the linkage conventions require that the program restore them before returning to its caller. >The whole save area thing has gotten to be a little bit of a pile IMHO. >It used to be the first two commandments: thou shalt do a >STM 14,12,12(13) on entry and thou shalt provide an 18-word save area >to callees. Now I am often in doubt and have to look up the rules and >then I am still in doubt. How many formats of save areas are there now? This is all documented in chapter 2 of the Assembler Services Guide. That chapter was extensively rewritten by Peter Relson for the z/OS 1.12 edition of the manual, and IMO it is now quite clear. The rules are simple. 1. When you call another program, register 13 contains the address of a save area that the called program will use to save your registers. The minimum size of that save area is whatever is required by the programs that you call. This is part of the called program's specifications. 2. When the caller receives control back when you return, o All 64 bits of General Purpose Registers 2 through 13 are unchanged from what they were when you received control. o AMODE is the same as it was when you received control. o Access Registers 2 through 13 are unchanged from what they were when you received control. o ASC mode is unchanged from what it was when you received control. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote: >And FWIW there is another overlapping complexity here besides AMODE 64 >-- speaking in theory only, because there is no reality of 64-bit COBOL. It isn't really "theory only" because it is true of assembler too. >There are really *three* kinds of module: those that are AMODE 64, >those that are AMODE 31 but use and/or count on the high halves of >registers, and those that are "pure" 31/32-bit. There are modules that use the high halves of registers and those that do not. Of those that do, some of them are AMODE(64) some of the time. Regardless of how a program uses the high halves of registers 2-12, the linkage conventions require that the program restore them before returning to its caller. >The whole save area thing has gotten to be a little bit of a pile IMHO. >It used to be the first two commandments: thou shalt do a >STM 14,12,12(13) on entry and thou shalt provide an 18-word save area >to callees. Now I am often in doubt and have to look up the rules and >then I am still in doubt. How many formats of save areas are there now? This is all documented in chapter 2 of the Assembler Services Guide. That chapter was extensively rewritten by Peter Relson for the z/OS 1.12 edition of the manual, and IMO it is now quite clear. The rules are simple. 1. When you call another program, register 13 contains the address of a save area that the called program will use to save your registers. The minimum size of that save area is whatever is required by the programs that you call. This is part of the called program's specifications. 2. When the caller receives control back when you return, o All 64 bits of General Purpose Registers 2 through 13 are unchanged from what they were when you received control. o AMODE is the same as it was when you received control. o Access Registers 2 through 13 are unchanged from what they were when you received control. o ASC mode is unchanged from what it was when you received control. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
> So fix the callee. The usual reasons for not doing so should not apply. Any code that uses grande instructions was by definition not written in 1972, so there should be no "we can't find the source code, the guy who wrote it retired, we're afraid to touch the code, ..." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, October 18, 2018 4:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit Don't expect anyone else to save it, so if you really need it after you get started then save again in your own storage before you call someone else who may or may not preserve it. I disagree. That's what linkage conventions are for. Sure, if a callee fails to follow them (and fails to document its requirements so that the caller can know that it needs to do extra work), the caller is screwed. So fix the callee. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
Don't expect anyone else to save it, so if you really need it after you get started then save again in your own storage before you call someone else who may or may not preserve it. I disagree. That's what linkage conventions are for. Sure, if a callee fails to follow them (and fails to document its requirements so that the caller can know that it needs to do extra work), the caller is screwed. So fix the callee. Must a 31-bit caller not depend on both halves of R2-R13 being preserved by a 31-bit subroutine? If it is truly a "subroutine" then it is owned by the caller and it is up to the caller to decide what its own rules are. If it is something not owned by the caller, then any caller (31-bit or otherwise) must be able to depend on both halves of R2-R13 being preserved (whether the target is 31-bit or otherwise). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
Nice thoughts, but I do not believe that is the rule. I believe the stated rule is that everyone must preserve high halves for their callers. If you break it, you put it back together before returning. See Peter Relson 6/14/2016 "LINK and high order word of R1." > If you use it, you save it and restore it for your caller. > save ... in your own storage before you call someone else A safe set of advice, but it ddoes imply lots of superfluous saving: save before calling, even if the callee might not modify, and even if the callee might be saving them itself. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Wednesday, October 17, 2018 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit The simple answer to the "problem child" case is not "don't do that", but instead: If you use it, you save it and restore it for your caller. Don't expect anyone else to save it, so if you really need it after you get started then save again in your own storage before you call someone else who may or may not preserve it. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, October 17, 2018 6:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote: >And FWIW there is another overlapping complexity here besides AMODE 64 -- >speaking in theory only, because there is no reality of 64-bit COBOL. > >... A program could be AMODE 31 but either destroy the high halves of a >caller's registers and/or expect a called program to preserve the high halves >of its registers. (There are many common uses of all 64 bits of a register >outside of AMODE 64.) > Sounds like a "Don't do that!" Must a 31-bit caller not depend on both halves of R2-R13 being preserved by a 31-bit subroutine? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
The simple answer to the "problem child" case is not "don't do that", but instead: If you use it, you save it and restore it for your caller. Don't expect anyone else to save it, so if you really need it after you get started then save again in your own storage before you call someone else who may or may not preserve it. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, October 17, 2018 6:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote: >And FWIW there is another overlapping complexity here besides AMODE 64 -- >speaking in theory only, because there is no reality of 64-bit COBOL. > >... A program could be AMODE 31 but either destroy the high halves of a >caller's registers and/or expect a called program to preserve the high halves >of its registers. (There are many common uses of all 64 bits of a register >outside of AMODE 64.) > Sounds like a "Don't do that!" Must a 31-bit caller not depend on both halves of R2-R13 being preserved by a 31-bit subroutine? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote: >And FWIW there is another overlapping complexity here besides AMODE 64 -- >speaking in theory only, because there is no reality of 64-bit COBOL. > >... A program could be AMODE 31 but either destroy the high halves of a >caller's registers and/or expect a called program to preserve the high halves >of its registers. (There are many common uses of all 64 bits of a register >outside of AMODE 64.) > Sounds like a "Don't do that!" Must a 31-bit caller not depend on both halves of R2-R13 being preserved by a 31-bit subroutine? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
And FWIW there is another overlapping complexity here besides AMODE 64 -- speaking in theory only, because there is no reality of 64-bit COBOL. There are really *three* kinds of module: those that are AMODE 64, those that are AMODE 31 but use and/or count on the high halves of registers, and those that are "pure" 31/32-bit. That middle case is a problem child. A program could be AMODE 31 but either destroy the high halves of a caller's registers and/or expect a called program to preserve the high halves of its registers. (There are many common uses of all 64 bits of a register outside of AMODE 64.) The whole save area thing has gotten to be a little bit of a pile IMHO. It used to be the first two commandments: thou shalt do a STM 14,12,12(13) on entry and thou shalt provide an 18-word save area to callees. Now I am often in doubt and have to look up the rules and then I am still in doubt. How many formats of save areas are there now? IMHO if IBM was going to go to a new linkage convention -- which in itself was a great idea -- they should have addressed 64-bit compatibility. I think AMODE 64 was very much on the horizon before XPLINK ever saw the light of day. I would think they might have come up with a convention that was almost as efficient as current XPLINK(31) but provided for straightforward calling among the three types of programs I listed above. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Wednesday, October 17, 2018 2:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit On Wed, 17 Oct 2018 15:37:12 -0500, Allan Kielstra wrote: >It is only available in 31-bit. > >An interesting question to ask is: if it were available in 64-bit but mixing >and matching 31- and 64-bit modules was not possible (i.e., you would have to >recompile all modules in an application), would that be interesting? Or is it >the case that it is vital to be able to selectively compile modules (in 64-bit >mode) and mix and match? Thank you for asking. While I was a COBOL programmer for several years, I have not worked in that role for decades. AMODE(64) COBOL could be a valuable tool for for applications that could benefit from very large tables. In many cases, such a conversion could be made by changing a relatively small number of modules if they could easily interoperate between AMODE(31) and AMODE(64) modules. The decision that was made that LE would support AMODE(64) only using XPLINK-64 made such interoperability difficult and expensive. XPLINK was invented to solve a particular problem, that C has a propensity for creating very small subroutines. XPLINK reduces the overhead in calling such subroutines somewhat. At the same time, it makes it rather expensive to call programs that use standard linkage. In addition, XPLINK-64 was designed in a way that makes it incompatible with 31-bit XPLINK. COBOL programs typically do a considerable amount of I/O to data sets, often using GET and PUT, which require standard linkage. If COBOL were to implement AMODE(64) in such a way that the standard FxSA save areas were used, it could more easily allow the interoperability of AMODE(64) with AMODE(31) programs without such additional overhead. PL/I already supports AMODE(64) to some extent, but only for applications that are entirely AMODE(64). The reason is XPLINK-64. As far as I know, it has not been adopted in any significant way, if at all. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
On Wed, 17 Oct 2018 15:37:12 -0500, Allan Kielstra wrote: >It is only available in 31-bit. > >An interesting question to ask is: if it were available in 64-bit but mixing >and matching 31- and 64-bit modules was not possible (i.e., you would have to >recompile all modules in an application), would that be interesting? Or is it >the case that it is vital to be able to selectively compile modules (in 64-bit >mode) and mix and match? Thank you for asking. While I was a COBOL programmer for several years, I have not worked in that role for decades. AMODE(64) COBOL could be a valuable tool for for applications that could benefit from very large tables. In many cases, such a conversion could be made by changing a relatively small number of modules if they could easily interoperate between AMODE(31) and AMODE(64) modules. The decision that was made that LE would support AMODE(64) only using XPLINK-64 made such interoperability difficult and expensive. XPLINK was invented to solve a particular problem, that C has a propensity for creating very small subroutines. XPLINK reduces the overhead in calling such subroutines somewhat. At the same time, it makes it rather expensive to call programs that use standard linkage. In addition, XPLINK-64 was designed in a way that makes it incompatible with 31-bit XPLINK. COBOL programs typically do a considerable amount of I/O to data sets, often using GET and PUT, which require standard linkage. If COBOL were to implement AMODE(64) in such a way that the standard FxSA save areas were used, it could more easily allow the interoperability of AMODE(64) with AMODE(31) programs without such additional overhead. PL/I already supports AMODE(64) to some extent, but only for applications that are entirely AMODE(64). The reason is XPLINK-64. As far as I know, it has not been adopted in any significant way, if at all. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
The following is just my personal $0.02USD worth. I speak for myself only and not for my employer. Just like any other new version of the COBOL compiler, 64-bit addressing support must be able to be phased in, subroutine by subroutine. Forcing all subroutines in a main program to become 64-bit if any one of them becomes 64-bit is NOT acceptable. Neither is any serious performance impact acceptable in mixed 64-bit-plus-31-bit programs, no matter what the starting addressing mode may be. In other words, do NOT use XPLINK for 64-bit COBOL. Find a better way that is far more compatible with current static and dynamic calling conventions. For one specific example, many (if not most) large z/OS shops have shop-wide application subroutines for I/O processing of application-specific files which all or at least many different applications in the shop use when they need to access those files. If one application program needs or desires to be recompiled for 64-bit support, there is no way that the application-specific shop-wide subroutine can be allowed to be recompiled as 64-bit because then every other application in the shop would all have to be converted to 64-bit at the same time. That can't (and won't) happen. Keeping separate libraries and separately-compiled versions for 64-bit and 31-bit subroutines may seem like a solution, but it is a management and SDLC maintenance nightmare. COBOL V5+ forced shops to support PDSE libraries for production application executables, but forking that into new separate libraries for 31-bit and 64-bit is just not practical or feasible. Every application would then have to test and maintain 2 versions of every common subroutine that they own, and there are no resources available to support that level of work. Most of us are already running as fast as we can to stay in one place, with no time to spare for anything else. Piecemeal, phased recompilation must be supported, without any serious performance penalties for either the newly compiled 64-bit programs or for the remaining 31-bit programs that are used in the same main program. It is acceptable for all-64-bit programs to have "better" performance (FSVO "better"), but impacting current SLA's because one subroutine became 64-bit is NOT acceptable. SLA's are already far too tight with no slack available. IBM must not screw this up with impossible-to-implement-in-the-real-world conditions or performance penalties. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra Sent: Wednesday, October 17, 2018 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit EXTERNAL EMAIL It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-bit modules was not possible (i.e., you would have to recompile all modules in an application), would that be interesting? Or is it the case that it is vital to be able to selectively compile modules (in 64-bit mode) and mix and match? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-bit modules was not possible (i.e., you would have to recompile all modules in an application), would that be interesting? Or is it the case that it is vital to be able to selectively compile modules (in 64-bit mode) and mix and match? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL 64bit
Just an easy question - does anyone know if COBOL can be 64 bit or is it still only 31 bit? Lizette Sent from EarthLink Mobile mail -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
In caarmm9rskjgk-ypgufnhowtvkpbjbykdk0cr2i3vnnrrurx...@mail.gmail.com, on 10/21/2014 at 11:59 AM, Tony Harminc t...@harminc.net said: Here's the epilog code for a non-main function generated by an oldish version of IBM C: Doesn't the use of R1 violate the czlling convention? 00011A 051E 00413 | BALR r1,r14 -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On 22 October 2014 18:34, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: Here's the epilog code for a non-main function generated by an oldish version of IBM C: Doesn't the use of R1 violate the czlling convention? It's an internal czll/rdturn, so they can do what they like. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Tony H wrote | It's an internal czll/rdturn, so they can | do what they like. Not quite. There was[is?] an internal-to-IBM scheme for requesting [and receiving] exceptions from programming standards which IBM PL/I development groups used fairly often. A cogent, chiefly technical case had to be made for each class of exceptions, and such requests were sometimes denied. Anciently, these exceptions were noted in PLMs and ELs. In this OCO era less is known about them. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
We do this always in our site-specific startup and return macros for ASSEMBLER programs; this way in save area trace, the program levels already returned show up by odd return addresses. It can be of some help in strange situations, where save area chains are partially destroyed. Kind regards Bernd Am 21.10.2014 17:42, schrieb Tom Marchant: On Tue, 21 Oct 2014 09:29:56 -0500, Paul Gilmartin wrote: I see in SYS1.MACLIB(RETURN): OI15(13),X'01' SET RETURN INDICATION 0160 Yes, It is done after the registers are restored, and it is only if T is specified after the registers to be restored. quote ,T Causes the control program to flag the save area used by the called program. The low-order bit of word 4 of the save area is set to 1 after the registers have been loaded; this designates that a called program has executed a return to its caller. Do not specify this parameter when returning control from an exit routine. /quote I think that this is very old behavior. I doubt that the option is used much. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Am 21.10.2014 19:53, schrieb Don Poitras: In article caarmm9rskjgk-ypgufnhowtvkpbjbykdk0cr2i3vnnrrurx...@mail.gmail.com you wrote: On 21 October 2014 10:09, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: I've never seen a case where BALR is used to return to the caller. Well... Here's the epilog code for a non-main function generated by an oldish version of IBM C: 00010EStart of Epilog 00010E 58D0 D00400413 | L r13,4(,r13) 000112 58E0 D00C00413 | L r14,12(,r13) 000116 9824 D01C00413 | LMr2,r4,28(r13) 00011A 051E 00413 | BALR r1,r14 00011C 0707 00413 | NOPR 7 00011E 000120Start of Literals 000120 0100018D=F'16777613' 000124 05000194=F'83886484' 000128 0900019A=F'150995354' 00012CEnd of Literals Why they use[d] BALR I don't know, but surely they don't plan to return to the NOPR and the certain program check that follows. Perhaps the NOPR can be changed to something else for debugging. Tony H. It's just a way to pass a parm to the library epilog routine. I would guess that '7' just means 'normal epilog'. The library looks at what R1+1 contains and makes various decisions based on the value. I don't think that the BALR R1,R14 calls a library epilog routine; the BALR R1,R14 goes back to the caller, because the return address to the caller (after the BALR R14,R15 etc.) has been loaded from the save area. If this should make any sense, then the caller should check R1 just after the call ... but that's normally what R15 is meant for (return code or function result in C). Debugging could be one reason for establishing such a return instruction instead of a normal BR 14 ... it would be interesting to see the compiler options of this old compile. Kind regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
There are several areas where LE does not agree well with the calling conventions, as I learned them in the mid 80s. - forward save area chaining (never done by LE, turning SYSUDUMP save area traces useless ... we fix this in our site specific interface modules, which are used between every two external module calls, be it dynamic linkage or static linkage) - the convention also implemented by SYSUDUMP, that entry points be documented by a text which starts at EPA + 5, with a one byte length field at EPA + 4. Today we always have x'01' and C'CEE' there; the compilers do it this way (although not all compilers are CEE compilers), and so the SYSUDUMP output of the save area trace, if any, looks like this: MODULE WAS CALLED AT EP C which does not help in any way. Our site specific dump routines, which replace SYSUDUMP etc., show at the same place the function (or CSECT) name of the programming language, be it PL/1, C, (C++) or ASSEMBLER ... coming from PPA2 ... and in certain situations the compile date. It would be very easy to get the same information in SYSUDUMP, too, if the function prolog would be compatible to SYSUDUMP standards, which, IMO, are part of the linkage conventions. BTW: these problems were not introduced with LE; they were already there which pre-LE versions of PL/1, for example (OS-PL/1 version 2.x). I first learned about these problems in 1991, when I started using PL/1 at my current customer's site. From 1984 to 1991 I only did ASSEMBLER on MVS (then), and I was kind of surprised in 1991, that the other languages did not conform to what I understood as being system standards. Kind regards Bernd Am 23.10.2014 18:16, schrieb Tony Harminc: On 22 October 2014 18:34, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: Here's the epilog code for a non-main function generated by an oldish version of IBM C: Doesn't the use of R1 violate the czlling convention? It's an internal czll/rdturn, so they can do what they like. Tony H. -- 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: 64bit
An AMODE 64 target routine often needs to edict whether it is to be entered by BASSM vs BASR/BALR (it cannot force that to be done, but it may misbehave if the edict is not followed). A fairly typical convention is for the target routine to capture the caller's AMODE in R14 via BSM 14,0 so that later it can do BSM 0,14. If the routine has preserved 64-bit R14, this works for all caller AMODEs. (An AMODE 64 BASR cannot be returned to by BSM 0,14 of the entry reg 14 without the sort of manipulation that BSM 14,0 does). The BSM-on-entry also can help to accommodate a call that might have been accomplished somewhat manually -- set reg 14, set reg 15, BR 15. But this approach does not work for BASSM, because it captures the target routine's AMODE rather than the caller's AMODE and thus a trailing BSM would return in the target routine's AMODE rather than the caller's AMODE. For BASSM linkage, that leading BSM needs not to be done, and in the general case there is no way to know. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Wed, Oct 22, 2014 at 6:46 AM, Peter Relson rel...@us.ibm.com wrote: An AMODE 64 target routine often needs to edict whether it is to be entered by BASSM vs BASR/BALR (it cannot force that to be done, but it may misbehave if the edict is not followed). I guess that using the return register to look at the preceding instruction to ensure it is a BASSM is covered by misbehave? Given my somewhat acerbic sense of humor, I would likely cause an S0C1, followed immediately by a short character string expressing displeasure with whomever wrote the offending calling code. Hopefully I won't be channeling Walter (Jeff Dunham character) at the time. -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Fri, 17 Oct 2014 16:36:38 -0400, Don Poitras wrote: I guess it depends what you mean by I would like to use 64bit storage for some functions from Cobol. If the Cobol part is never going to directly use the memory, then there's no problem in a called program in another language using above the bar storage. Just remember to SAM 31 before you return to Cobol (unless you use one of the calls that automatically returns you in the correct amode.) If you have an assembler called program, you don't need to issue SAM31 before returning as long as you were called with one of BASSM, BASR or BALR. In all of these cases the return register (R14) contains sufficient information so that BSM will return correctly. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant On Fri, 17 Oct 2014 16:36:38 -0400, Don Poitras wrote: I guess it depends what you mean by I would like to use 64bit storage for some functions from Cobol. If the Cobol part is never going to directly use the memory, then there's no problem in a called program in another language using above the bar storage. Just remember to SAM 31 before you return to Cobol (unless you use one of the calls that automatically returns you in the correct amode.) If you have an assembler called program, you don't need to issue SAM31 before returning as long as you were called with one of BASSM, BASR or BALR. In all of these cases the return register (R14) contains sufficient information so that BSM will return correctly. But see APAR PI17184 for an instance when BSM did not return correctly. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Tue, 21 Oct 2014 07:30:32 -0500, Tom Marchant wrote: If you have an assembler called program, you don't need to issue SAM31 before returning as long as you were called with one of BASSM, BASR or BALR. In all of these cases the return register (R14) contains sufficient information so that BSM will return correctly. How does the content of R14 distinguish between the cases: o Caller in AMODE 24 o Caller in AMODE 64; Return Address 16MiB? And, even, between: o Caller in AMODE 31 o Caller in AMODE 64; 6GiB = Return Address 8GiB? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Chase, John wrote: But see APAR PI17184 for an instance when BSM did not return correctly. Curious PER, hmmm. Is that only for COBOL 5.1 programs running under CICS? With what LE version is that APAR? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Tue, 21 Oct 2014 13:31:44 +, Chase, John wrote: From: IBM Mainframe Discussion List On Behalf Of Tom Marchant If you have an assembler called program, you don't need to issue SAM31 before returning as long as you were called with one of BASSM, BASR or BALR. In all of these cases the return register (R14) contains sufficient information so that BSM will return correctly. But see APAR PI17184 for an instance when BSM did not return correctly. That's why I hedged my post the way I did. It is not at all clear to me that LE always used BASSM, BALR or BASR to call. The APAR information is confusing, at least to me. quote Normally this is not an issue with GOBACK, since BALR is used to return to the caller. However, when LE stack frame exit is introduced to the stack chain, the CEEHSFXA routine will get control and BSM is used to return to the caller instead. /quote I've never seen a case where BALR is used to return to the caller. I think I may have seen where BSM is used by the caller to pass control to the called program. In particular, where there is an interface routine (glue code) between the calling application and the called program. So, yes, if your program changes the AMODE after receiving control, you should change it back to what it was. And not just blindly set it to AMODE 31. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Tue, 21 Oct 2014 08:49:26 -0500, Paul Gilmartin wrote: On Tue, 21 Oct 2014 07:30:32 -0500, Tom Marchant wrote: If you have an assembler called program, you don't need to issue SAM31 before returning as long as you were called with one of BASSM, BASR or BALR. In all of these cases the return register (R14) contains sufficient information so that BSM will return correctly. How does the content of R14 distinguish between the cases: o Caller in AMODE 24 o Caller in AMODE 64; Return Address 16MiB? And, even, between: o Caller in AMODE 31 o Caller in AMODE 64; 6GiB = Return Address 8GiB? I stand corrected. BALR and BASR do not set bit 63 of the return register if in AMODE 64, so what I wrote earlier applies only to AMODE 24 or 31 callers using those instructions. BASSM always provides the correct information for BSM to correctly return to the calling program. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Chase, John wrote: But see APAR PI17184 for an instance when BSM did not return correctly. Curious PER, hmmm. Is that only for COBOL 5.1 programs running under CICS? That was the situation when I opened the PMR for which the APAR was opened. Presumably it could have occurred in a batch program as well. With what LE version is that APAR? z/OS 1.13 (HLE7780) -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Tue, 21 Oct 2014 09:18:52 -0500, Tom Marchant wrote: I stand corrected. BALR and BASR do not set bit 63 of the return register if in AMODE 64, so what I wrote earlier applies only to AMODE 24 or 31 callers using those instructions. BASSM always provides the correct information for BSM to correctly return to the calling program. Thanks. I'm not up to date on my P[ro]Op reading, and was ignorant of the bit 63 behavior. FWIW, I see in SYS1.MACLIB(RETURN): OI15(13),X'01' SET RETURN INDICATION 0160 BASSM has some minor conflict with this convention. I doubt that it matters. Does anyone inspect this indication in dumps? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Chase, John wrote: Curious PER, hmmm. Is that only for COBOL 5.1 programs running under CICS? That was the situation when I opened the PMR for which the APAR was opened. Presumably it could have occurred in a batch program as well. Ok. With what LE version is that APAR? z/OS 1.13 (HLE7780) Thanks. Much better written than those hastily written 'Release level 780' in the APAR. I really wish those IBMers working with APARs would write the [full] set of programs and their releases properly. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Tom Marchant wrote: begin extract So, yes, if your program changes the AMODE after receiving control, you should change it back to what it was. And not just blindly set it to AMODE 31. /end extract and this is supremely good generic advice. I am hard put even to fantasticate a situation in which it is not appropriate. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Tue, 21 Oct 2014 09:29:56 -0500, Paul Gilmartin wrote: I see in SYS1.MACLIB(RETURN): OI15(13),X'01' SET RETURN INDICATION 0160 Yes, It is done after the registers are restored, and it is only if T is specified after the registers to be restored. quote ,T Causes the control program to flag the save area used by the called program. The low-order bit of word 4 of the save area is set to 1 after the registers have been loaded; this designates that a called program has executed a return to its caller. Do not specify this parameter when returning control from an exit routine. /quote I think that this is very old behavior. I doubt that the option is used much. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On 21 October 2014 10:09, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: I've never seen a case where BALR is used to return to the caller. Well... Here's the epilog code for a non-main function generated by an oldish version of IBM C: 00010EStart of Epilog 00010E 58D0 D00400413 | L r13,4(,r13) 000112 58E0 D00C00413 | L r14,12(,r13) 000116 9824 D01C00413 | LMr2,r4,28(r13) 00011A 051E 00413 | BALR r1,r14 00011C 0707 00413 | NOPR 7 00011E 000120Start of Literals 000120 0100018D=F'16777613' 000124 05000194=F'83886484' 000128 0900019A=F'150995354' 00012CEnd of Literals Why they use[d] BALR I don't know, but surely they don't plan to return to the NOPR and the certain program check that follows. Perhaps the NOPR can be changed to something else for debugging. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
In article caarmm9rskjgk-ypgufnhowtvkpbjbykdk0cr2i3vnnrrurx...@mail.gmail.com you wrote: On 21 October 2014 10:09, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: I've never seen a case where BALR is used to return to the caller. Well... Here's the epilog code for a non-main function generated by an oldish version of IBM C: 00010EStart of Epilog 00010E 58D0 D00400413 | L r13,4(,r13) 000112 58E0 D00C00413 | L r14,12(,r13) 000116 9824 D01C00413 | LMr2,r4,28(r13) 00011A 051E 00413 | BALR r1,r14 00011C 0707 00413 | NOPR 7 00011E 000120Start of Literals 000120 0100018D=F'16777613' 000124 05000194=F'83886484' 000128 0900019A=F'150995354' 00012CEnd of Literals Why they use[d] BALR I don't know, but surely they don't plan to return to the NOPR and the certain program check that follows. Perhaps the NOPR can be changed to something else for debugging. Tony H. It's just a way to pass a parm to the library epilog routine. I would guess that '7' just means 'normal epilog'. The library looks at what R1+1 contains and makes various decisions based on the value. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Part of the reason for going to a new backend (code generator/optimizer) in COBOL V5.1 was that the new backend already supports AMODE 64. This is another step in the direction of AMODE 64 COBOL. The first steps were to get infrastructure in LE, get AMODE 64 support for COBOL into plan for CICS, DB2 and DFSORT, and make sure that all of the players are playin'! AMODE 64 COBOL is already in our plans, but it is not going to be in V5.x. Sorry, we are working on it, but we may be too late to help you Scott! Cheers, TomR COBOL is the Language of the Future! Scott - I think that only enterprise cobol 5.x support 64 bit natively. Sam On Thu, Oct 16, 2014 at 7:17 AM, Scott Ford 0006f84450fa-dmarc-requ...@listserv.ua.edu wrote: All, I have a generalized design question. First background will help. Our products run as Enterprise Cobol STC, no multi-tasking, yet. We call hlasm subroutines. I would like to use 64bit storage for some functions from Cobol. Is this feasible. I think it is, where I am unclear is the call and binder parameters. Do I have to do anything special parameter wise ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Tom, No problem..I want to head our products toward 64bit ..So changing our existing COBOL code was my first choice. But it looks like I will head us for C or C++ with Assembler called routines. But I appreciate the email for sure. Regards, Scott www.identityforge From: Tom Ross Sent: Monday, October 20, 2014 8:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Part of the reason for going to a new backend (code generator/optimizer) in COBOL V5.1 was that the new backend already supports AMODE 64. This is another step in the direction of AMODE 64 COBOL. The first steps were to get infrastructure in LE, get AMODE 64 support for COBOL into plan for CICS, DB2 and DFSORT, and make sure that all of the players are playin'! AMODE 64 COBOL is already in our plans, but it is not going to be in V5.x. Sorry, we are working on it, but we may be too late to help you Scott! Cheers, TomR COBOL is the Language of the Future! Scott - I think that only enterprise cobol 5.x support 64 bit natively. Sam On Thu, Oct 16, 2014 at 7:17 AM, Scott Ford 0006f84450fa-dmarc-requ...@listserv.ua.edu wrote: All, I have a generalized design question. First background will help. Our products run as Enterprise Cobol STC, no multi-tasking, yet. We call hlasm subroutines. I would like to use 64bit storage for some functions from Cobol. Is this feasible. I think it is, where I am unclear is the call and binder parameters. Do I have to do anything special parameter wise ? -- 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: 64bit
As I read thru the MVS Extended Addressability Guide I am trying to understand restrictions, In general, you should assume that a z/OS service does not support AMODE 64 unless it says it does. In general, you should assume that a z/OS service that supports AMODE 64 does not support data above 2G unless it says it does. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Sat, 18 Oct 2014 10:11:15 -0400, Peter Relson wrote: In general, you should assume that a z/OS service that supports AMODE 64 does not support data above 2G unless it says it does. If it does not, there's not a whole lot of rationale for (claiming to) support AMODE 64. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
It means junk that happens to be in the high 32 bits of a register won't mess us up. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, October 18, 2014 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit On Sat, 18 Oct 2014 10:11:15 -0400, Peter Relson wrote: In general, you should assume that a z/OS service that supports AMODE 64 does not support data above 2G unless it says it does. If it does not, there's not a whole lot of rationale for (claiming to) support AMODE 64. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Never mind. Should not post before coffee. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, October 18, 2014 8:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit It means junk that happens to be in the high 32 bits of a register won't mess us up. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, October 18, 2014 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit On Sat, 18 Oct 2014 10:11:15 -0400, Peter Relson wrote: In general, you should assume that a z/OS service that supports AMODE 64 does not support data above 2G unless it says it does. If it does not, there's not a whole lot of rationale for (claiming to) support AMODE 64. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Paul, There would certainly be no rationale for having AMODE(64) if there were no above-the-bar virtual storage. Since, however, we do have this storage there is sometimes a rationale for using AMODE(64) below the bar, and the ability to invoke a facility from AMODE(64) code is then also valuable. It reduces the need for mode switching and its associated prologues and epilogues, if nothing else. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
It's as much as I can do just to spell CoBOL but, as far as I can tell, it's not ready for prime time. Even its most avid proponent signs off thus: TomR COBOL is the Language of the Future! We are trapped in the present. We cannot get to the future. The nearest we can get to the future is the latest, most recent, current instance of the present. Ergo, CoBOL is not for us. 'Nuff said! ;-) === Date: Thu, 16 Oct 2014 10:17:56 -0400 From: 0006f84450fa-dmarc-requ...@listserv.ua.edu Subject: 64bit To: IBM-MAIN@LISTSERV.UA.EDU All, I have a generalized design question. First background will help. Our products run as Enterprise Cobol STC, no multi-tasking, yet. We call hlasm subroutines. I would like to use 64bit storage for some functions from Cobol. Is this feasible. I think it is, where I am unclear is the call and binder parameters. Do I have to do anything special parameter wise ? Thanks as always, Regards, Scott ford www.identityforge.com - www.idmworks.com from my IPAD -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Sat, 18 Oct 2014 11:16:13 -0400, John Gilmore wrote: There would certainly be no rationale for having AMODE(64) if there were no above-the-bar virtual storage. Since, however, we do have this storage there is sometimes a rationale for using AMODE(64) below the bar, and the ability to invoke a facility from AMODE(64) code is then also valuable. It reduces the need for mode switching and its associated prologues and epilogues, if nothing else. Having been through this (but not to successful completion) in the 370-XA transition when I had to obtain contol blocks below the line and add interface code below the line, and cursing IBM not for shirking the former (which is harder), but for shirking the latter (which is easier; they've done it at last), it was perhaps easy for me to intend more irony than you perceived. It's still far from the level of compatibility of being able to code EXEC PGM=ASMA90,PARM='64-bit,...' and being able to supply a 370 source program unmodified and letting conditional assembly handle the compatibility. The GET macro might test the AMODE and generate code to interface to either a DCB or a DCBE (or in the future a DCBG) as suitable. C comes rather close to this with its #ifdefs, but not entirely, as previous plies in this thread suggest. On Fri, 17 Oct 2014 20:12:58 -0500, John McKown wrote: Most likely not of any use to you, but have you looked at GnuCOBOL? It was OpenCOBOL, but has been taken over by GNU / FSF as one of their languages. It works by translating COBOL to C and then compiling the C code. If nothing else, it might give you some ideas. http://sourceforge.net/projects/open-cobol/ . Of course, it does not run on z/OS, ... I thought that was only because you haven't finished porting it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Perhaps I misunderstood the problem. Whether called by the system, Cobol, or anything else, an HLASM routine can get any storage that its authorization allows it to. That includes storage below the bar, above the bar, and in data spaces. The routine can switch in and out of any AMODE that its RMODE allows (e.g., an RMODE 31 program better not SAM24). The caller needs to provide parameters in the form that the HLASM routine wants (or conversely the HLASM routine needs to accommodate the parameters that the caller provides; this is probably the easier approach). If you need the calling routine to then be able to deal with the storage above 2G, that's a different matter entirely. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
I was interpreting Scott's question as how can above-the-bar memory be used directly by COBOL. On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson rel...@us.ibm.com wrote: Perhaps I misunderstood the problem. Whether called by the system, Cobol, or anything else, an HLASM routine can get any storage that its authorization allows it to. That includes storage below the bar, above the bar, and in data spaces. The routine can switch in and out of any AMODE that its RMODE allows (e.g., an RMODE 31 program better not SAM24). The caller needs to provide parameters in the form that the HLASM routine wants (or conversely the HLASM routine needs to accommodate the parameters that the caller provides; this is probably the easier approach). If you need the calling routine to then be able to deal with the storage above 2G, that's a different matter entirely. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
In article CAFMxNWL0GLo1kCpEMokfozjhqVBN8VyUHUON4eWxC=c5Y=8...@mail.gmail.com you wrote: I was interpreting Scott's question as how can above-the-bar memory be used directly by COBOL. Which is why Peter was confused. No such support currently exists. While there's been a lot of talk about AMODE 64 COBOL, it's not there today. On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson rel...@us.ibm.com wrote: Perhaps I misunderstood the problem. Whether called by the system, Cobol, or anything else, an HLASM routine can get any storage that its authorization allows it to. That includes storage below the bar, above the bar, and in data spaces. The routine can switch in and out of any AMODE that its RMODE allows (e.g., an RMODE 31 program better not SAM24). The caller needs to provide parameters in the form that the HLASM routine wants (or conversely the HLASM routine needs to accommodate the parameters that the caller provides; this is probably the easier approach). If you need the calling routine to then be able to deal with the storage above 2G, that's a different matter entirely. Peter Relson z/OS Core Technology Design -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
All, C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If I am just using 64bit storage to store/retrieve data that should work? Scott ford www.identityforge.com from my IPAD On Oct 17, 2014, at 2:11 PM, Don Poitras poit...@pobox.com wrote: In article CAFMxNWL0GLo1kCpEMokfozjhqVBN8VyUHUON4eWxC=c5Y=8...@mail.gmail.com you wrote: I was interpreting Scott's question as how can above-the-bar memory be used directly by COBOL. Which is why Peter was confused. No such support currently exists. While there's been a lot of talk about AMODE 64 COBOL, it's not there today. On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson rel...@us.ibm.com wrote: Perhaps I misunderstood the problem. Whether called by the system, Cobol, or anything else, an HLASM routine can get any storage that its authorization allows it to. That includes storage below the bar, above the bar, and in data spaces. The routine can switch in and out of any AMODE that its RMODE allows (e.g., an RMODE 31 program better not SAM24). The caller needs to provide parameters in the form that the HLASM routine wants (or conversely the HLASM routine needs to accommodate the parameters that the caller provides; this is probably the easier approach). If you need the calling routine to then be able to deal with the storage above 2G, that's a different matter entirely. Peter Relson z/OS Core Technology Design -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
I guess it depends what you mean by I would like to use 64bit storage for some functions from Cobol. If the Cobol part is never going to directly use the memory, then there's no problem in a called program in another language using above the bar storage. Just remember to SAM 31 before you return to Cobol (unless you use one of the calls that automatically returns you in the correct amode.) In article 1dacd255-b881-4e84-b5df-129a12ce4...@yahoo.com you wrote: All, C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If I am just using 64bit storage to store/retrieve data that should work? Scott ford www.identityforge.com from my IPAD On Oct 17, 2014, at 2:11 PM, Don Poitras poit...@pobox.com wrote: In article CAFMxNWL0GLo1kCpEMokfozjhqVBN8VyUHUON4eWxC=c5Y=8...@mail.gmail.com you wrote: I was interpreting Scott's question as how can above-the-bar memory be used directly by COBOL. Which is why Peter was confused. No such support currently exists. While there's been a lot of talk about AMODE 64 COBOL, it's not there today. On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson rel...@us.ibm.com wrote: Perhaps I misunderstood the problem. Whether called by the system, Cobol, or anything else, an HLASM routine can get any storage that its authorization allows it to. That includes storage below the bar, above the bar, and in data spaces. The routine can switch in and out of any AMODE that its RMODE allows (e.g., an RMODE 31 program better not SAM24). The caller needs to provide parameters in the form that the HLASM routine wants (or conversely the HLASM routine needs to accommodate the parameters that the caller provides; this is probably the easier approach). If you need the calling routine to then be able to deal with the storage above 2G, that's a different matter entirely. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
COBOL can talk to any legal assembler program. But it can only manipulate data below the bar. Scenario one: COBOL program creates records in memory and passes them to assembler program, which does something with them that involves above the bar memory. That will work. Scenario two: COBOL program calls assembler code which retrieves data from above the bar and copies it into a buffer provided by the COBOL program. That will work. Scenario three: COBOL program calls assembler code which finds data above the bar and passes its address to the COBOL program. That will not work. (Technically, that would sort-of work, but the COBOL program would have no way of seeing the data and manipulating it. All it could do is pass the address to some other assembler program.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, October 17, 2014 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit All, C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If I am just using 64bit storage to store/retrieve data that should work? Scott ford www.identityforge.com from my IPAD On Oct 17, 2014, at 2:11 PM, Don Poitras poit...@pobox.com wrote: In article CAFMxNWL0GLo1kCpEMokfozjhqVBN8VyUHUON4eWxC=c5Y=8...@mail.gmail.com you wrote: I was interpreting Scott's question as how can above-the-bar memory be used directly by COBOL. Which is why Peter was confused. No such support currently exists. While there's been a lot of talk about AMODE 64 COBOL, it's not there today. On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson rel...@us.ibm.com wrote: Perhaps I misunderstood the problem. Whether called by the system, Cobol, or anything else, an HLASM routine can get any storage that its authorization allows it to. That includes storage below the bar, above the bar, and in data spaces. The routine can switch in and out of any AMODE that its RMODE allows (e.g., an RMODE 31 program better not SAM24). The caller needs to provide parameters in the form that the HLASM routine wants (or conversely the HLASM routine needs to accommodate the parameters that the caller provides; this is probably the easier approach). If you need the calling routine to then be able to deal with the storage above 2G, that's a different matter entirely. Peter Relson z/OS Core Technology Design -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Charles, The more I see the more I want/will convert the Cobol code to C or C++. Scott ford www.identityforge.com from my IPAD On Oct 17, 2014, at 4:46 PM, Charles Mills charl...@mcn.org wrote: COBOL can talk to any legal assembler program. But it can only manipulate data below the bar. Scenario one: COBOL program creates records in memory and passes them to assembler program, which does something with them that involves above the bar memory. That will work. Scenario two: COBOL program calls assembler code which retrieves data from above the bar and copies it into a buffer provided by the COBOL program. That will work. Scenario three: COBOL program calls assembler code which finds data above the bar and passes its address to the COBOL program. That will not work. (Technically, that would sort-of work, but the COBOL program would have no way of seeing the data and manipulating it. All it could do is pass the address to some other assembler program.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, October 17, 2014 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit All, C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If I am just using 64bit storage to store/retrieve data that should work? Scott ford www.identityforge.com from my IPAD On Oct 17, 2014, at 2:11 PM, Don Poitras poit...@pobox.com wrote: In article CAFMxNWL0GLo1kCpEMokfozjhqVBN8VyUHUON4eWxC=c5Y=8...@mail.gmail.com you wrote: I was interpreting Scott's question as how can above-the-bar memory be used directly by COBOL. Which is why Peter was confused. No such support currently exists. While there's been a lot of talk about AMODE 64 COBOL, it's not there today. On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson rel...@us.ibm.com wrote: Perhaps I misunderstood the problem. Whether called by the system, Cobol, or anything else, an HLASM routine can get any storage that its authorization allows it to. That includes storage below the bar, above the bar, and in data spaces. The routine can switch in and out of any AMODE that its RMODE allows (e.g., an RMODE 31 program better not SAM24). The caller needs to provide parameters in the form that the HLASM routine wants (or conversely the HLASM routine needs to accommodate the parameters that the caller provides; this is probably the easier approach). If you need the calling routine to then be able to deal with the storage above 2G, that's a different matter entirely. Peter Relson z/OS Core Technology Design -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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: 64bit
These remarks of mine may produce some reactions ... I have not done any 64-bit work in C/C++, but the number of this is not available in AMODE 64 and this behaves differently in AMODE 64 notes would give me pause. I have a requirement/enhancement that would be perfect for above-the-bar from C++ but I am nervous about undertaking it that way for that reason. There seem to be in general so many unexpected interdependencies among various C/LE options. I needed to interface to the GSK encryption. That required POSIX(ON). All went well until final testing, when a stupid little utility program that was supposed to be loadable from COBOL suddenly was not. Why not? COBOL can't load a POSIX(ON) C program. Really? Really. In addition to this sort of gotcha be aware of the inherent/documented differences. In 32-bit C, for example, a uint and a size_t are the same thing -- you can pass of a size_t to a method with uint * in its prototype; but in AMODE 64 C they are not the same thing and you cannot. Don't get me wrong. I love XLC. Could not do what I am doing without it. But AMODE 64 C gives me pause. I would love to hear that I am wrong. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, October 17, 2014 1:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit Charles, The more I see the more I want/will convert the Cobol code to C or C++. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Charles: I couldn't have said it any better. I also want to use 64bit as I eluded to in my previous note. As I read thru the MVS Extended Addressability Guide I am trying to understand restrictions, especially when you in a mixed Language environment. I have done a lot of looking in the LE Language Guide, Ref and ILC guides and see bits and pieces of 64bit examples and mixed ( working ) language examples. John Ehrman’s 64bit Share.org presentation was excellent as was Ed’s. I am not bashing IBM, but I don't understand why there isn't more information in both areas. I feel there are probably more areas. Mostly because the dinosaurs like us are retiring and information is being lost. Regards, Scott www.identityforge.com - www.idmworks.com From: Charles Mills Sent: Friday, October 17, 2014 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU These remarks of mine may produce some reactions ... I have not done any 64-bit work in C/C++, but the number of this is not available in AMODE 64 and this behaves differently in AMODE 64 notes would give me pause. I have a requirement/enhancement that would be perfect for above-the-bar from C++ but I am nervous about undertaking it that way for that reason. There seem to be in general so many unexpected interdependencies among various C/LE options. I needed to interface to the GSK encryption. That required POSIX(ON). All went well until final testing, when a stupid little utility program that was supposed to be loadable from COBOL suddenly was not. Why not? COBOL can't load a POSIX(ON) C program. Really? Really. In addition to this sort of gotcha be aware of the inherent/documented differences. In 32-bit C, for example, a uint and a size_t are the same thing -- you can pass of a size_t to a method with uint * in its prototype; but in AMODE 64 C they are not the same thing and you cannot. Don't get me wrong. I love XLC. Could not do what I am doing without it. But AMODE 64 C gives me pause. I would love to hear that I am wrong. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, October 17, 2014 1:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit Charles, The more I see the more I want/will convert the Cobol code to C or C++. -- 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: 64bit
I have just converted a large C program from 31-bit to 64-bit because MQ Series Version 8 now supports LP64. There are 28 modules and no Metal C code as this app runs on many different platforms. All called assembler subroutines, z/OS-only, are now AMODE 64 and a number do switches internally to AMODE 31 in order to call 3rd party software that is either RMODE 24 or 31 (because of old I/O, etc.) All this works fine at this point even loading and walking through AMODE 31 load modules that are just DSECTs with internal pointers to various control blocks. The DSECT modules are also 3rd party so we can't change them. Calling the executables via the assembler code requires you to use __ptr32 in the C code for the variables to be passed to the 3rd party code and then using only the 2nd word of each entry in the parm list passed to the AMODE 64 assembler routine for restructuring the parm list for the 3rd party software. So far this is working better than originally anticipated and was quite simple to implement. There were some odd changes to address the DSECT Load modules and internal blocks as the original code worked on z/OS AMODE 31 and zLinux, multiple UNIX environments, Wintel Linux and Windows in AMODE 64. John T. Abell President International Software Products Tel: 800-295-7608 Ext: 224 International: 1-416-593-5578 Ext: 224 Fax: 800-295-7609 International: 1-416-593-5579 E-mail: john.ab...@intnlsoftwareproducts.com Web: www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, October 17, 2014 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit These remarks of mine may produce some reactions ... I have not done any 64-bit work in C/C++, but the number of this is not available in AMODE 64 and this behaves differently in AMODE 64 notes would give me pause. I have a requirement/enhancement that would be perfect for above-the-bar from C++ but I am nervous about undertaking it that way for that reason. There seem to be in general so many unexpected interdependencies among various C/LE options. I needed to interface to the GSK encryption. That required POSIX(ON). All went well until final testing, when a stupid little utility program that was supposed to be loadable from COBOL suddenly was not. Why not? COBOL can't load a POSIX(ON) C program. Really? Really. In addition to this sort of gotcha be aware of the inherent/documented differences. In 32-bit C, for example, a uint and a size_t are the same thing -- you can pass of a size_t to a method with uint * in its prototype; but in AMODE 64 C they are not the same thing and you cannot. Don't get me wrong. I love XLC. Could not do what I am doing without it. But AMODE 64 C gives me pause. I would love to hear that I am wrong. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, October 17, 2014 1:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit Charles, The more I see the more I want/will convert the Cobol code to C or C++. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Most likely not of any use to you, but have you looked at GnuCOBOL? It was OpenCOBOL, but has been taken over by GNU / FSF as one of their languages. It works by translating COBOL to C and then compiling the C code. If nothing else, it might give you some ideas. http://sourceforge.net/projects/open-cobol/ . Of course, it does not run on z/OS, but does on Linux and Windows. So you could try it out by downloading something to your PC and using GnuCOBOL on it. Something like: cobc -std=ibm -C -fsign-ebcdic cobol-source.cbl I actually tried this on a small number of little program from my shop. The source compiled. I don't know if it would actually _work_ because I didn't have all the necessary file to actually run anything. On Fri, Oct 17, 2014 at 3:55 PM, Scott Ford 0006f84450fa-dmarc-requ...@listserv.ua.edu wrote: Charles, The more I see the more I want/will convert the Cobol code to C or C++. Scott ford www.identityforge.com from my IPAD On Oct 17, 2014, at 4:46 PM, Charles Mills charl...@mcn.org wrote: COBOL can talk to any legal assembler program. But it can only manipulate data below the bar. Scenario one: COBOL program creates records in memory and passes them to assembler program, which does something with them that involves above the bar memory. That will work. Scenario two: COBOL program calls assembler code which retrieves data from above the bar and copies it into a buffer provided by the COBOL program. That will work. Scenario three: COBOL program calls assembler code which finds data above the bar and passes its address to the COBOL program. That will not work. (Technically, that would sort-of work, but the COBOL program would have no way of seeing the data and manipulating it. All it could do is pass the address to some other assembler program.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, October 17, 2014 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit All, C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If I am just using 64bit storage to store/retrieve data that should work? Scott ford www.identityforge.com from my IPAD On Oct 17, 2014, at 2:11 PM, Don Poitras poit...@pobox.com wrote: In article CAFMxNWL0GLo1kCpEMokfozjhqVBN8VyUHUON4eWxC=c5Y=8...@mail.gmail.com you wrote: I was interpreting Scott's question as how can above-the-bar memory be used directly by COBOL. Which is why Peter was confused. No such support currently exists. While there's been a lot of talk about AMODE 64 COBOL, it's not there today. On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson rel...@us.ibm.com wrote: Perhaps I misunderstood the problem. Whether called by the system, Cobol, or anything else, an HLASM routine can get any storage that its authorization allows it to. That includes storage below the bar, above the bar, and in data spaces. The routine can switch in and out of any AMODE that its RMODE allows (e.g., an RMODE 31 program better not SAM24). The caller needs to provide parameters in the form that the HLASM routine wants (or conversely the HLASM routine needs to accommodate the parameters that the caller provides; this is probably the easier approach). If you need the calling routine to then be able to deal with the storage above 2G, that's a different matter entirely. Peter Relson z/OS Core Technology Design -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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 -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On 18/10/2014 5:19 AM, Charles Mills wrote: In addition to this sort of gotcha be aware of the inherent/documented differences. In 32-bit C, for example, a uint and a size_t are the same thing -- you can pass of a size_t to a method with uint * in its prototype; but in AMODE 64 C they are not the same thing and you cannot. What's uint? I can't find it in stdint.h. I can however find uint32_t, uint64_t etc which explicitly state the number of bits in the type definition name. I always use the typedefs in stdint.h as a matter of course (cstdint for C++). There's also a __ptr32 definition. The only issue I run into with 64bit C/C++ code is having to deal with assembler service routines that were written for 32bit. And you can't just recompile with a different compiler option to make them 64bit! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
You're right. uchar but no uint. You got my drift. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Friday, October 17, 2014 7:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit On 18/10/2014 5:19 AM, Charles Mills wrote: In addition to this sort of gotcha be aware of the inherent/documented differences. In 32-bit C, for example, a uint and a size_t are the same thing -- you can pass of a size_t to a method with uint * in its prototype; but in AMODE 64 C they are not the same thing and you cannot. What's uint? I can't find it in stdint.h. I can however find uint32_t, uint64_t etc which explicitly state the number of bits in the type definition name. I always use the typedefs in stdint.h as a matter of course (cstdint for C++). There's also a __ptr32 definition. The only issue I run into with 64bit C/C++ code is having to deal with assembler service routines that were written for 32bit. And you can't just recompile with a different compiler option to make them 64bit! -- 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
64bit
All, I have a generalized design question. First background will help. Our products run as Enterprise Cobol STC, no multi-tasking, yet. We call hlasm subroutines. I would like to use 64bit storage for some functions from Cobol. Is this feasible. I think it is, where I am unclear is the call and binder parameters. Do I have to do anything special parameter wise ? Thanks as always, Regards, Scott ford www.identityforge.com - www.idmworks.com from my IPAD -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Scott - I think that only enterprise cobol 5.x support 64 bit natively. Sam On Thu, Oct 16, 2014 at 7:17 AM, Scott Ford 0006f84450fa-dmarc-requ...@listserv.ua.edu wrote: All, I have a generalized design question. First background will help. Our products run as Enterprise Cobol STC, no multi-tasking, yet. We call hlasm subroutines. I would like to use 64bit storage for some functions from Cobol. Is this feasible. I think it is, where I am unclear is the call and binder parameters. Do I have to do anything special parameter wise ? Thanks as always, Regards, Scott ford www.identityforge.com - www.idmworks.com from my IPAD -- 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
