Re: Decimal Floating Point Numbers
Thanks, Abe. I'm glad I was able to help. I don't really understand why they started with this whole LUV/RUV thing anyway. They could have just picked one and said that that's the representation and left it at that (no pun intended!). But I guess that wouldn't have been confusing enough. Take care, Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of Abe Kornelis Sent: Wednesday, March 6, 2024 12:31 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Gary, thanks for explaining. I had to enumerate the options to get to understand it... When encoding 7 with LUV, the decimal point is always after the first digit. Within the cohort, there are - as you mentioned - various members: 7.00E0 - Biased Exp = 95 0.70E1 - Biased Exp = 96 0.07E2 - Biased Exp = 97 0.007000E3 - Biased Exp = 98 0.000700E4 - Biased Exp = 99 0.70E5 - Biased Exp = 100 0.07E6 - Biased Exp = 101 When encoding 7 with RUV, the decimal point is always after the last digit. Within the cohort, there are - again - various members. E.g. 007E0 - Biased Exp = 101 070E-1 - Biased Exp = 100 700E-2 - Biased Exp = 99 0007000E-3 - Biased Exp = 98 007E-4 - Biased Exp = 97 070E-5 - Biased Exp = 96 700E-6 - Biased Exp = 95 Which clearly shows that in the encoded format the RUV vs LUV is not relevant. Thanks a lot for helping me understand. Kind regards, Abe === Op 05/03/2024 om 18:19 schreef Gary L Peskin: > But you need to look at the bias for the exponent. Both views would be > encoded the same. I guess I didn't explain this very well before but this > example will help. For the short format, there are 7 significant digits. > For the LUV, bias of the exponent is 95. For the RUV, bias of the exponent > is 101. See this in figure 20-2 that we mentioned before. > > Also, I think we're getting cohorts mixed up with LUV/RUV. What you're > showing below are two different members of a cohort. Not too different views > of the same representation. But that's another story. I think you'll see what > I mean below. > > Let's take the number 7. This can be encoded with the LUV as 7.00 x > 10**0 or as 700. x 10**-6. In both cases the significand is represented > the exact same as 700. For LUV, the decimal point is implied to the > right of the seven. For RUV, the implied decimal is to the right of the > rightmost zero. > > For LUV, the unbiased exponent is 95 since 95 - 95 = 0. > For RUV, the unbiased exponent is 95 since 95 - 101 = -6. > > So in BOTH cases, the unbiased exponent (which is what is encoded in > the representation in memory) is 95. And in both cases the significand > is encoded as 700. The representation in memory is the SAME. It's > just a matter of whether you want to look at as > > 7.00 x 10 * (95-95) > -or- > 700 x 10 * (95-101) > > I hope this example helps. > > Take care, > Gary > > -Original Message- > From: IBM Mainframe Assembler List > On Behalf Of Abe Kornelis > Sent: Tuesday, March 5, 2024 8:58 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Decimal Floating Point Numbers > > Hi Peter, > > thanks for your response. Nice to hear from you :-) > > They would be encoded quite differently. > Say you'd encode the value seven. > In LUV this would be 7.0*10**0 > In RUV this would be 07*10**0 > > In either case the number of zero digits would depend on the format of > the DFP: D/E/X > > For the sake of completeness: > In LUV the digit 7 would go into the combination field In RUV the digit would > be at the end of the significand. > > Unless I am quite mistaken, which is still quite conceivable :-( > > Kind regards, > Abe > === > > > Op 05/03/2024 om 15:19 schreef Peter Relson: >> I am imagining (and could easily be wrong) that the hex data is identical >> across the views (and thus the instruction implementation does not care >> about the view), and it's only a question of which bits you choose to look >> at (or what arithmetic logical manipulation you use) if formatting the value >> for human consumption. >> >> For example, the exponent differs, as does the significand (a term I had not >> known of until seeing it in the POp). >> >> I don't know what kind of dump was being looked at, but perhaps there's a >> formatting option within the dump viewing program that might say "show me >> this as a Right-Unit View DFP value". >> >> Peter Relson >> z/OS Core Technology Design
Re: Decimal Floating Point Numbers
But you need to look at the bias for the exponent. Both views would be encoded the same. I guess I didn't explain this very well before but this example will help. For the short format, there are 7 significant digits. For the LUV, bias of the exponent is 95. For the RUV, bias of the exponent is 101. See this in figure 20-2 that we mentioned before. Also, I think we're getting cohorts mixed up with LUV/RUV. What you're showing below are two different members of a cohort. Not too different views of the same representation. But that's another story. I think you'll see what I mean below. Let's take the number 7. This can be encoded with the LUV as 7.00 x 10**0 or as 700. x 10**-6. In both cases the significand is represented the exact same as 700. For LUV, the decimal point is implied to the right of the seven. For RUV, the implied decimal is to the right of the rightmost zero. For LUV, the unbiased exponent is 95 since 95 - 95 = 0. For RUV, the unbiased exponent is 95 since 95 - 101 = -6. So in BOTH cases, the unbiased exponent (which is what is encoded in the representation in memory) is 95. And in both cases the significand is encoded as 700. The representation in memory is the SAME. It's just a matter of whether you want to look at as 7.00 x 10 * (95-95) -or- 700 x 10 * (95-101) I hope this example helps. Take care, Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of Abe Kornelis Sent: Tuesday, March 5, 2024 8:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Hi Peter, thanks for your response. Nice to hear from you :-) They would be encoded quite differently. Say you'd encode the value seven. In LUV this would be 7.0*10**0 In RUV this would be 07*10**0 In either case the number of zero digits would depend on the format of the DFP: D/E/X For the sake of completeness: In LUV the digit 7 would go into the combination field In RUV the digit would be at the end of the significand. Unless I am quite mistaken, which is still quite conceivable :-( Kind regards, Abe === Op 05/03/2024 om 15:19 schreef Peter Relson: > I am imagining (and could easily be wrong) that the hex data is identical > across the views (and thus the instruction implementation does not care about > the view), and it's only a question of which bits you choose to look at (or > what arithmetic logical manipulation you use) if formatting the value for > human consumption. > > For example, the exponent differs, as does the significand (a term I had not > known of until seeing it in the POp). > > I don't know what kind of dump was being looked at, but perhaps there's a > formatting option within the dump viewing program that might say "show me > this as a Right-Unit View DFP value". > > Peter Relson > z/OS Core Technology Design
Re: Decimal Floating Point Numbers
Abe. I think you're still missing the point. I'll reply to a later message to straighten this out. Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of Abe Kornelis Sent: Monday, March 4, 2024 3:24 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Hi Gary, Thanks for the PoP quote. I must have missed that one. Otherwise, I roughly got as far as you did. One can move the (virtual) decimal point at will, provided you adjust the exponent value accordingly. When e.g. adding two DFP numbers, the LUV vs. RUV does not seem to matter - the addition results are the same in either case. When adding a RUV-encoded value to a LUV-encoded value the addition is bound to produce rubbish. So it seems relevant to know how to distinguish. Since the processor seems not to make the distinction, I think I must be something... Kind regards, Abe === Op 04/03/2024 om 09:08 schreef Gary L Peskin: > Hi, Abe - > > > > In the version of the PoP that I'm looking at, it states that ". Except where > otherwise indicated, ...DFP [is defined] in terms of the right-units view. So > I think that's just a convention in the documentation. > > > > As far as LUV vs RUV, a given value is represented the same in a register or > storage regardless of whether you view it as LUV or RUV. These are just > "views" at the number. You can view it as if the decimal point is either to > the right of the leftmost digit (LUV) or to the right of the rightmost digit > (RUV). In other words it's sort of like saying 1.234 * 102 (LUV) is the same > as 1234 * 10-1 (RUV). If you look carefully, you’ll see that the biases for > the exponent in figure 20-2 differ by the same amount as the number of digits > in the significand. By considering the bias as having changed, it just > accounts for where the decimal point is even though the representation is the > same. It’s just a question of how you want to view the number. I probably > didn’t explain this very well but I hope you get the idea. > > > > Frankly, I think this whole LUV vs RUV discussion is more confusing than > helpful but I guess some people like to think of their numbers as x. * > 10y and others prefer to think of them as x * 10z. > > > > And figure 9-1 is just showing the possible range of values with an unbiased > exponent. It’s not meant to indicate any representation of the top/bottom of > the range in memory which uses biased exponents. > > > > HTH, > > Gary > > > > -Original Message- > From: IBM Mainframe Assembler List > On Behalf Of Abe Kornelis > Sent: Sunday, March 3, 2024 10:29 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Decimal Floating Point Numbers > > > > All, > > > > There's something with decimal floating point numbers that has been eluding > me for a long time. > > > > According to PoP chapter 20, DFP numbers may be encoded as either Left-Units > View or Right-Units View. > > As shown in e.g. figure 20-2. > > > > Yet when looking at a DFP value in a dump, it seems to be impossible to tell > which view applies. > > Just like a packed decimal does not have the decimal point encoded - you just > have to know where the programmer decided it to be. > > Is it indeed like that with LUV vs. RUV - you just have to know? > > > > Additionally, figure 9-1 lists only the RUV values; no mention is made of LUV > representation limits. > > Instruction descriptions equally make no mention of LUV vs. RUV. > > > > To me it appears the instruction always treat the data as RUV. Is this > correct? > > Or am I missing something obvious? > > > > Thanks in advance, > > Abe Kornelis. > > ==
Re: Decimal Floating Point Numbers
Hi, Abe - In the version of the PoP that I'm looking at, it states that ". Except where otherwise indicated, ...DFP [is defined] in terms of the right-units view. So I think that's just a convention in the documentation. As far as LUV vs RUV, a given value is represented the same in a register or storage regardless of whether you view it as LUV or RUV. These are just "views" at the number. You can view it as if the decimal point is either to the right of the leftmost digit (LUV) or to the right of the rightmost digit (RUV). In other words it's sort of like saying 1.234 * 102 (LUV) is the same as 1234 * 10-1 (RUV). If you look carefully, you’ll see that the biases for the exponent in figure 20-2 differ by the same amount as the number of digits in the significand. By considering the bias as having changed, it just accounts for where the decimal point is even though the representation is the same. It’s just a question of how you want to view the number. I probably didn’t explain this very well but I hope you get the idea. Frankly, I think this whole LUV vs RUV discussion is more confusing than helpful but I guess some people like to think of their numbers as x. * 10y and others prefer to think of them as x * 10z. And figure 9-1 is just showing the possible range of values with an unbiased exponent. It’s not meant to indicate any representation of the top/bottom of the range in memory which uses biased exponents. HTH, Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of Abe Kornelis Sent: Sunday, March 3, 2024 10:29 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Decimal Floating Point Numbers All, There's something with decimal floating point numbers that has been eluding me for a long time. According to PoP chapter 20, DFP numbers may be encoded as either Left-Units View or Right-Units View. As shown in e.g. figure 20-2. Yet when looking at a DFP value in a dump, it seems to be impossible to tell which view applies. Just like a packed decimal does not have the decimal point encoded - you just have to know where the programmer decided it to be. Is it indeed like that with LUV vs. RUV - you just have to know? Additionally, figure 9-1 lists only the RUV values; no mention is made of LUV representation limits. Instruction descriptions equally make no mention of LUV vs. RUV. To me it appears the instruction always treat the data as RUV. Is this correct? Or am I missing something obvious? Thanks in advance, Abe Kornelis. ==
Re: Scholarly Articles Evaluation Report Was Case Study: IBM SYSTEM/360/37 0 ARCHITECTURE (1987)
Hi, Paul -- This is now called the National Security Agency / Central Security Service. According to this web page https://www.nsa.gov/business/contacts/, you might try contacting the NSA/CSS Commercial Solutions Center at +1.240.373.4163 (i...@nsa.gov) and see if they know of such a report on z/OS. Thanks, Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of esst...@juno.com Sent: Sunday, August 9, 2020 9:59 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Scholarly Articles Evaluation Report Was Case Study: IBM SYSTEM/360/37 0 ARCHITECTURE (1987) Hello..I stumbled into a Scholarly Articles Web Page containing two IBM Evaluation Reports one for MVS/XA and another for MVS/ESA https://scholar.google.com/scholar?q=IBM+Region-Control-task&hl=en&as_sdt=0&; as_vis=1&oi=scholart National Computer Security Center Final Evaluation Report International Business Machines MVS/XA with RACF 1.8 apps.dtic.mil Final Evaluation Report International Business Machines MVS/ESA Operating System dtic.mil . . Is anyone familiar with these reports and know where I can find the equivalent evaluation for os/390 and most importantly z/OS ? . . Paul D'Angelo .
Re: BAKR Instruction
Hi, Paul -- In a BAKR R14,R15 instruction, the R14 value is the value to which the branched-to routine will return when it executes the PR. So your statement "Register 14 (operand 1) would contain the next sequential instruction" is correct if you're talking about the value of R14 _before_ the execution of the BAKR. If you want the branched-to routine to return to the instruction after the BAKR, you should code BAKR 0,R15. This will save the instruction after the BAKR as the return value in the linkage stack. Depending on what R14 was set to before the BAKR was executed, this would explain the behavior that you're seeing. The value in the register denoted by operand 1 (in this case R14) is unaffected by the BAKR instruction. HTH, Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of esst...@juno.com Sent: Sunday, May 27, 2018 4:10 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: BAKR Instruction Hi, . Question About the BAKR Instruction . . I thought I understood the BAKR instruction. . I load the address of a load module into Register 15 Then I issue a BAKR R14,R15 . My understanding is that a Linkage stack entry is created And The PSW would be updated with the Address in R15 (operand 2). Register 14 (operand 1) would contain the next sequential instruction. . Do I understand this correctly. . The Sub-routine which was brought into memory via a LOAD does get invoked. . It does not have a BAKR not a SAVE macro as its first instruction. It actually issues an LARL instruction to set a Base Register and then issues a STORAGE OBTAIN to get working storage. . When The Sub-Routine exits and returns to the calling module. It issues a STORAGE Release and a Program Return (PR) instruction. . There is a WTO Identifying the SUB-Routine was entered and another WTO stating the SUB-Routine is exiting. . What it looks like - is the PR instruction returns to the beginning of the Sub-Routine as it goes into a loop producing thousands of wto Entering and Exiting Messages. . Any Ideas as to how to proceed. . Paul D'Angelo . .
Re: BPAM multiple members/one DCB and EODAD exit?
Hi, Dave - As I read the docs, NOTE only works after a READ or WRITE. You'll get an invalid value if you use it after a FIND or POINT. Gary -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Thomas David Rivers Sent: Friday, January 8, 2016 2:31 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: BPAM multiple members/one DCB and EODAD exit? I'm having a heck of a time reading multiple members from the same BPAM DCB... but not sequentially, trying to "skip around" in the members (for example, read one block of MEM1, one block of MEM2, back to MEM1 to read the next block, back to MEM2 to read the next block, etc...) This is input only. I'm using NOTE + FIND&POINT to switch between members. That is, when I need to switch to a different member, I remember the current TTR with a NOTE, then a I do a FIND for the other member and POINT to it's remembered TTR. As it happens, MEM1 only has one block, while MEM2 has many... Now - for my questions... This is the behavior I'm seeing with my operations (results in the comments): FIND MEM1 NOTE- returns TTR X'11B00' READreads a short first block CHECK * NOTE- returns TTR X'11C00', remembers as the current TTR for MEM1 FIND MEM2 NOTE- returns TTR X'11000' READ correctly reads first block of MEM2 CHECK * NOTE - returns TTR X'11100' * * Return back to processing MEM1 * FIND MEM1 POINT X'11C00' Point back to remembered TTR for MEM1 NOTE <*** RETURNs X'11B00' - not the block I just POINTed to READ CHECK * Check drives my EOD exit, so END-OF-DATA is noted for MEM1 * * Return back to processing MEM2 * FIND MEM2 POINT X'11100' Point back to remembered TTR for MEM2 NOTE <*** RETURNSs X'11000' - not the block I just POINTed to READ CHECK <*** Drives EOD exit * END-OF-DATA noted for MEM2 So - my questions (that I hope someone can illuminate) are: 1) Why does the NOTE following a successful POINT indicate a different TTR (it seems to indicate the preceeding TTR.) 2) MEM2 has many more blocks in it, but my EOD exit is driven when attempting to read the 2nd block, even though I did a FIND and POINT to reposition. It seems once the EOD of a member is found, others suffer the same fate? I've gone through my code to look for errors (such as passing the wrong value to POINT, etc...) but nothing "obvious" appears wrong. And, I've verified that the EODAD is being driven on the subsequent read of MEM2. What I'm trying to do is keep the same DCB and process multiple members, "bouncing" between them; without suffering a new OPEN for each. I did some googling to see if I could find some sample code for this; but I've been unsuccessful. The IBM documentation seems to indicate this it the proper approach; but it's only mentioned under PDSEs... is it not valid for PDSs? I have code that can keep the same DCB open for reading more than one member of a PDS; but it reads the entire member before moving to the next.. and in this new situation I only want to read part of a member, and then return to it after reading part of a different member... Any pointers would be appreciated... - Many thanks! - - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Assembler XPLINK parameters > 3
Hi, Kirk -- Don't you need to bias R4 by adding +2048 (CEEDSAHP_BIAS) to it? In other words, isn't R4 really pointing to DSA - CEEDSAHP_BIAS? Gary > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of Kirk Wolf > Sent: Monday, February 07, 2011 10:00 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Assembler XPLINK parameters > 3 > > I'm having a bit of trouble decoding the information on how to get the > paramters in a called 31-bit XPLINK assembler program. > > I'm doing the following, but its not giving me correct values for parms > 4-5. > > > MYFUNC EDCXPRLG BASEREG=NONE,PARMWRDS=5 > USING DSA,R4 > LMR8,R9,PARM4 load parms 4 and 5 > ... > EDCXEPLG , > DSA CEEDSA SECTYPE=XPLINK > ORG CEEDSAHP_ARGLIST > PARM4DS F > PARM5DS F > YREGS > END
Re: Self-defining terms
See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASMR1020/9.9.2?SH ELF=ez2zo112&DT=20080711003624 > Am 14.12.2010 19:52, schrieb Abe F. Kornelis: > > All, > > > > with the help of John Kalinich (thanks John) I am trying to port a > > program from z390 to HLASM. > > We're encountering something strange with a self-defining term. Please > > take a look at the following piece of code: > > GBLC&HEXVAL,&DECVAL * Input, output of HEX2DEC > > LCLA&MAJOPCD,&MINOPCD * Major, minor opcodes > > ... * Other code > > MNOTE 4,'findo...@106 DECVAL=&DECVAL' **!! > > &MAJOPCD SETA (&DECVAL) > > &MINOPCD SETA -1 * No minor opcode > > > > > > In the listing it generates the following sequence (please mind line- > wraps): > > ** ASMA254I *** MNOTE *** 44277+ 4,findo...@106 DECVAL=- > 1 02-FINDO > > ** ASMA102E Arithmetic term is not self-defining term; default=0 - > FINDO/DECVAL > > ** ASMA435I Record 107 in AD.ABE.MACLIB(FINDOPCD) on volume: PERM61 > > ** ASMA013S ACTR counter exceeded - HTMLG > > ** ASMA435I Record 670 in AD.ABE.MACLIB(HTMLGEN) on volume: PERM61 > > > > > From this output I deduce the following: > > 1) The variable&DECVAL holds character string with value '-1' > > 2) Error ASMA102E indicates HLASM cannot assign this value to the SETA > > variable&MAJOPCD > > 3) The next error as indicated by the ASMA013S message occurs much > later, > > so the assignment at line 108 is executed correctly! > > > > So that leaves me with the question why the first SETA fails on a > > negative number, while the second one does accept a negative self- > defining term. > > Checking the manual only adds to the confusion: it states that > > negative self-defining terms are not acceptable. Still the assignment > > to&MINOPCD at line 108 in the macro is accepted by HLASM. > > > > Does anybody have an explanation? Am I missing something? > > > > Thanks in advance, > > Abe Kornelis. > > == > >
Re: NSLOOKUP vs BPX1GHN
Sorry, this Subject was tagged with a [SPAM] notation on my end and I neglected to remove it before I replied. Gary > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of Gary L Peskin > Sent: Saturday, November 27, 2010 11:16 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: [SPAM] NSLOOKUP vs BPX1GHN > > Assuming that PLIST points to a valid remote parameter list, I think > that your best bet is to dump PLIST before the call to make sure it > looks okay and to turn on Trace Resolver output with a > > //SYSTCPT DD SYSOUT=* > > I'm not sure how you're getting your base resolver files. Have a look > at > http://publib.boulder.ibm.com/infocenter/zos/v1r9/topic/com.ibm.zos.r9.h > alz0 > 02/mvsso.htm#mvsso which explains how the base resolver configuration > file is located. > > Gary > > > -Original Message- > > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > > l...@listserv.uga.edu] On Behalf Of esst...@juno.com > > Sent: Saturday, November 27, 2010 7:31 AM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: [SPAM] NSLOOKUP vs BPX1GHN > > > > This probably is not the right forum for this question. > > But the people on this forum seem to be more knowledgeable. I have > > used BPX1GHN before to retrieve an ip-address for a given "Host Name". > > > > Im not sure I understand why I cant consistently retrieve a ip-address > > for Host Name. I consistently receive a not found or un-known host? > > Return code of 1 and Reason Code of X '1004' > > When I issue NSLOOKUP command from TSO 6, NSLOOKUP does return an ip- > > address and a server name. > > > > I also understand that NSLOOKUP and BPX1GHN uses different methologies > > to locate the host name. It is my understanding that BPX1GHN uses the > > TCP/IP Resolver service to resolve the host name through a name > server. > > BPX1GHN may also need to search the HOSTS.SITEINFO dataset. > > > > NSLOOKUP on the otherhand uses multiple socket and resolver service > > calls (a lower level servoice call). > > > > I have posted code snipets below. > > > > Not being a Network Or TCP Person can someone explain why I Can not > > retrieve the ip-address from a host name via BPX1GHN ? As I mentioned > > earlier I have used BPX1GHN at other installations. I do have an OMVS > > segment defined to me RACF id. > > > > I dont understand why I continue to receive UNKNOWN HOST for BPX1GHN. > > > > > > > > MVC BPXEYE,=C'BPXPARMS' Eye Catcher > > > > XCBPXSAVE,BPXSAVE Register Save Area > > > > XCHOST_NAME,HOST_NAME > > > > LAR0,00 > > > > STR0,BPXVAL Return Value > > > > STR0,BPXRETCD Return Code > > > > STR0,BPXRSNCD Reason Code > > > > STR0,HOST_ENT@Address Of Host Name Stru > > > > LAR0,L'C_SYSAHIP Length Of Host Name > > > > STR0,HOST_NAME# Length Of Host Name > > > > MVC HOST_NAME(L'C_SYSAHIP),C_SYSAHIP > > > > * > > > > LOAD EP=BPX1GHNLoad BPX Module > > > > STM R15,R1,LOADREGS Save Registers From Load > > > > STR0,BPX1GHN@ Save Address Of BPX1GHN > > > > * > > > > L R15,BPX1GHN@ Get Address Of BPX1GHN > > > > CALL (15), Get host by name > > > >(HOST_NAME, Input: Name of Host being queried > > > >HOST_NAME#, Input: Length of host name > > > >HOST_ENT@,Output: 0 or -> HOSTENT structure > > > >BPXVAL, Return code > > > >BPXRETCD, Return code > > > >BPXRSNCD),Reason code > > > >LINKINST=BASR, > > > >VL,MF=(E,PLIST) - > - > > > > * > > > > > > > > > > > > *** > > *** > > > > BPXPARMS DSECT > > > > BPXSAVE DS9DRegister Save Area > > > > BPXEYE DSD <=EYE CATCHER > > > > BPXVAL DSA > > > > BPXRETCD DSA Return Code > > > > BPXRSNCD DSA Reason Code > > > > HOST_ENT@ DS A Address Of Host Name Structure > > > > HOST_NAME# DS A Length Of Host Name > > > > HOST_NAME DS CL255 Host Name > > > > BPXPARMS# EQU *-BPXPARMSSTRUCTURE LENGTH > > > > *** > > *** > > > > > > > > Paul D'Angelo
Re: [SPAM] NSLOOKUP vs BPX1GHN
Assuming that PLIST points to a valid remote parameter list, I think that your best bet is to dump PLIST before the call to make sure it looks okay and to turn on Trace Resolver output with a //SYSTCPT DD SYSOUT=* I'm not sure how you're getting your base resolver files. Have a look at http://publib.boulder.ibm.com/infocenter/zos/v1r9/topic/com.ibm.zos.r9.halz0 02/mvsso.htm#mvsso which explains how the base resolver configuration file is located. Gary > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of esst...@juno.com > Sent: Saturday, November 27, 2010 7:31 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: [SPAM] NSLOOKUP vs BPX1GHN > > This probably is not the right forum for this question. > But the people on this forum seem to be more knowledgeable. I have used > BPX1GHN before to retrieve an ip-address for a given "Host Name". > > Im not sure I understand why I cant consistently retrieve a ip-address > for Host Name. I consistently receive a not found or un-known host? > Return code of 1 and Reason Code of X '1004' > When I issue NSLOOKUP command from TSO 6, NSLOOKUP does return an ip- > address and a server name. > > I also understand that NSLOOKUP and BPX1GHN uses different methologies > to locate the host name. It is my understanding that BPX1GHN uses the > TCP/IP Resolver service to resolve the host name through a name server. > BPX1GHN may also need to search the HOSTS.SITEINFO dataset. > > NSLOOKUP on the otherhand uses multiple socket and resolver service > calls (a lower level servoice call). > > I have posted code snipets below. > > Not being a Network Or TCP Person can someone explain why I Can not > retrieve the ip-address from a host name via BPX1GHN ? As I mentioned > earlier I have used BPX1GHN at other installations. I do have an OMVS > segment defined to me RACF id. > > I dont understand why I continue to receive UNKNOWN HOST for BPX1GHN. > > > > MVC BPXEYE,=C'BPXPARMS' Eye Catcher > > XCBPXSAVE,BPXSAVE Register Save Area > > XCHOST_NAME,HOST_NAME > > LAR0,00 > > STR0,BPXVAL Return Value > > STR0,BPXRETCD Return Code > > STR0,BPXRSNCD Reason Code > > STR0,HOST_ENT@Address Of Host Name Stru > > LAR0,L'C_SYSAHIP Length Of Host Name > > STR0,HOST_NAME# Length Of Host Name > > MVC HOST_NAME(L'C_SYSAHIP),C_SYSAHIP > > * > > LOAD EP=BPX1GHNLoad BPX Module > > STM R15,R1,LOADREGS Save Registers From Load > > STR0,BPX1GHN@ Save Address Of BPX1GHN > > * > > L R15,BPX1GHN@ Get Address Of BPX1GHN > > CALL (15), Get host by name > >(HOST_NAME, Input: Name of Host being queried > >HOST_NAME#, Input: Length of host name > >HOST_ENT@,Output: 0 or -> HOSTENT structure > >BPXVAL, Return code > >BPXRETCD, Return code > >BPXRSNCD),Reason code > >LINKINST=BASR, > >VL,MF=(E,PLIST) -- > > * > > > > > > *** > *** > > BPXPARMS DSECT > > BPXSAVE DS9DRegister Save Area > > BPXEYE DSD <=EYE CATCHER > > BPXVAL DSA > > BPXRETCD DSA Return Code > > BPXRSNCD DSA Reason Code > > HOST_ENT@ DS A Address Of Host Name Structure > > HOST_NAME# DS A Length Of Host Name > > HOST_NAME DS CL255 Host Name > > BPXPARMS# EQU *-BPXPARMSSTRUCTURE LENGTH > > *** > *** > > > > Paul D'Angelo
Re: Number of added instructions?
Thanks everyone for your prompt responses. At the end of the day, I think I'll just go with what John Gilmore suggests and say that there are many more instructions that there used to be. With some embellishment, it will get across the point that I'm trying to make. Thanks, Gary > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of Martin Trübner > Sent: Tuesday, August 31, 2010 9:25 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Number of added instructions? > > Tony, > > >> ...a few more than 6 of the old privops have gone. > > John counted/referenced 360 and I believe that he is right...I > counted 13, but I had such "new" stuff like LRA in my list. > > >> ... more than 6 of the old privops have gone. SSK/ISK and RRB > >> come to mind, > > RRB was not on 360- introduced later and retired meanwhile. > > And only because 2K pages are not sufficient (since ), because IBM > has said so. Japanese boxes had 2K pages way beyond 16M (and no problem > with that) (as long as you switched them to use 4K pages when having > more than 16M on an IBM op-sys). > > -- > Martin > > Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at > http://www.picapcpu.de
Number of added instructions?
I'm doing a presentation and wanted to quickly mention how the mainframe architecture instruction set has grown. Does anyone happen to know the number of different unprivileged machine instructions there were in the early 370 days versus the latest soon-to-be-released z/Architecture instruction set? Thanks, Gary
