Re: finding DU-AL in a dump
Hmm Sounds like you are trying to say, "I know 'that task' (not the one I am currently running under) has stuff aleserv'ed on it's access list and I want to be able to look at it's data." I'd say this is a security issue the system probably wants to prohibit. Essentially you want an aleserv extract that will work against any TCB you point it to. I know of no such feature. For security purposes it would be up to the owning task to communicate the stokens to your task so you can aleserv it onto your own access list. Since it's your app, maybe you can locate the stokens and aleserv them under the task your test is running under?? Beyond that, I think you would have to (knowing what the alets are) do the translations manually from that task's du-al. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Thursday, March 30, 2023 6:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: finding DU-AL in a dump I’m not interested in the PASN You want me to be specfic ok I have to Alets that I ALESERV ed To WORKUNIT=AL One is the Alet of another address space the other is a dataspace that I created in a SRB scope=all I put data into it running under TESTAUTH I cannt display it What I would like to is write a customized TESTAUTH subcommand that would go into the debugged TCB which I can get from the TCOMTAB get any Alets associated with it And display the Data in this dataspace > On Mar 30, 2023, at 6:09 PM, Glen Garrison wrote: > > So you are trying to determine, at any given point in time, if a task or > srb has anything at all aleserv'ed? From a task perspective, you can find > the du-al as we have walked through. But if someone running under that task > has aleserv'ed to the pasn I know of no way you can identify that.The > du-al is unique to a task but there is nothing in the pasn side that is task > related that you would be able to locate and associate with a specific task, > that I know of. > I can't say I know the cross memory services task termination/supervisor > functionality or programming requirements for owning a dataspace (for > example) and having added it to the pasn. So I don't really know how they > clean up an in-use pasn ale, made in use by a task that may be going away. > (I say going away because that would require them to identify a specific ale > by task.)I support real storage manager so my knowledge is on the > dataspace and dat translation side. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Thursday, March 30, 2023 5:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: finding DU-AL in a dump > > Chapter 5 in the pops book is program execution on page 5-46 is access > register introduction being an ALET is loaded onto an access register > would reading up on that give me a better understanding of doing what > I want to do > > I mean finding/if there are any alets for that TASK/SRB > > thanks > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Glen Garrison > Sent: Thursday, March 30, 2023 4:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: finding DU-AL in a dump > > The du-al, as well as the pasn are access LISTS. Tables used to translate an > alet to the correct DAT structures for the "space" you have aleserv'ed onto > the list. Aleserv add obtains an entry in the list for your request and > assigns it to your request and builds the alet based on the index of the > entry chosen.You have to know the alet to get to the correct ale and then > aste for the 'space' you are trying to translate to.Since there can be > multiple valid entries in the access list, to get to the correct one you must > know the index in the alet. If you're lucky, yours is the only one on the > list and you can scan to see it but that's by chance. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Thursday, March 30, 2023 3:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: finding DU-AL in a dump > > How did you come up with that ? I’ll Look > > Is there anyway figuring it out with our knowing the alet > > I mean maybe by starting at the bottom And looking for a non zero > entry > >> On Mar 30, 2023, at 3:41 PM, Glen Garrison wrote: >> >> Take the last 2 bytes of your alet, multiply by x'10' and add to the >> value of stcbalov. (index into the du-al). That gets you to the ALE >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Joseph Reichman >>
Re: finding DU-AL in a dump
So you are trying to determine, at any given point in time, if a task or srb has anything at all aleserv'ed? From a task perspective, you can find the du-al as we have walked through. But if someone running under that task has aleserv'ed to the pasn I know of no way you can identify that.The du-al is unique to a task but there is nothing in the pasn side that is task related that you would be able to locate and associate with a specific task, that I know of. I can't say I know the cross memory services task termination/supervisor functionality or programming requirements for owning a dataspace (for example) and having added it to the pasn. So I don't really know how they clean up an in-use pasn ale, made in use by a task that may be going away. (I say going away because that would require them to identify a specific ale by task.)I support real storage manager so my knowledge is on the dataspace and dat translation side. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Thursday, March 30, 2023 5:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: finding DU-AL in a dump Chapter 5 in the pops book is program execution on page 5-46 is access register introduction being an ALET is loaded onto an access register would reading up on that give me a better understanding of doing what I want to do I mean finding/if there are any alets for that TASK/SRB thanks -Original Message- From: IBM Mainframe Discussion List On Behalf Of Glen Garrison Sent: Thursday, March 30, 2023 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finding DU-AL in a dump The du-al, as well as the pasn are access LISTS. Tables used to translate an alet to the correct DAT structures for the "space" you have aleserv'ed onto the list. Aleserv add obtains an entry in the list for your request and assigns it to your request and builds the alet based on the index of the entry chosen. You have to know the alet to get to the correct ale and then aste for the 'space' you are trying to translate to.Since there can be multiple valid entries in the access list, to get to the correct one you must know the index in the alet. If you're lucky, yours is the only one on the list and you can scan to see it but that's by chance. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Thursday, March 30, 2023 3:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: finding DU-AL in a dump How did you come up with that ? I’ll Look Is there anyway figuring it out with our knowing the alet I mean maybe by starting at the bottom And looking for a non zero entry > On Mar 30, 2023, at 3:41 PM, Glen Garrison wrote: > > Take the last 2 bytes of your alet, multiply by x'10' and add to the > value of stcbalov. (index into the du-al). That gets you to the ALE > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Thursday, March 30, 2023 8:44 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] finding DU-AL in a dump > > Hi > > v > > I have two ALETS one from an address space one from a dataspace they > are both on DU-AL I put them there via ALESERV AL=WORKUNIT > > > > I am looking for them in a dump > > > > I know the acronym ALE: in a dump stands for Access list element > > > > I also know that STCBALOV offset X'20 from the STCB for the TCB I am > running under points to it > > > > At that are all I see is X'8... not my two alets > > > > I see the same in a dump. > > > > Under the ALE: heading. > > > > Just wondering where I would find them. > > > > Thanks > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message
Re: finding DU-AL in a dump
The du-al, as well as the pasn are access LISTS. Tables used to translate an alet to the correct DAT structures for the "space" you have aleserv'ed onto the list. Aleserv add obtains an entry in the list for your request and assigns it to your request and builds the alet based on the index of the entry chosen. You have to know the alet to get to the correct ale and then aste for the 'space' you are trying to translate to.Since there can be multiple valid entries in the access list, to get to the correct one you must know the index in the alet. If you're lucky, yours is the only one on the list and you can scan to see it but that's by chance. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Thursday, March 30, 2023 3:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: finding DU-AL in a dump How did you come up with that ? I’ll Look Is there anyway figuring it out with our knowing the alet I mean maybe by starting at the bottom And looking for a non zero entry > On Mar 30, 2023, at 3:41 PM, Glen Garrison wrote: > > Take the last 2 bytes of your alet, multiply by x'10' and add to the > value of stcbalov. (index into the du-al). That gets you to the ALE > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Thursday, March 30, 2023 8:44 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] finding DU-AL in a dump > > Hi > > v > > I have two ALETS one from an address space one from a dataspace they > are both on DU-AL I put them there via ALESERV AL=WORKUNIT > > > > I am looking for them in a dump > > > > I know the acronym ALE: in a dump stands for Access list element > > > > I also know that STCBALOV offset X'20 from the STCB for the TCB I am > running under points to it > > > > At that are all I see is X'8... not my two alets > > > > I see the same in a dump. > > > > Under the ALE: heading. > > > > Just wondering where I would find them. > > > > Thanks > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding DU-AL in a dump
Take the last 2 bytes of your alet, multiply by x'10' and add to the value of stcbalov. (index into the du-al). That gets you to the ALE -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Thursday, March 30, 2023 8:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] finding DU-AL in a dump Hi v I have two ALETS one from an address space one from a dataspace they are both on DU-AL I put them there via ALESERV AL=WORKUNIT I am looking for them in a dump I know the acronym ALE: in a dump stands for Access list element I also know that STCBALOV offset X'20 from the STCB for the TCB I am running under points to it At that are all I see is X'8... not my two alets I see the same in a dump. Under the ALE: heading. Just wondering where I would find them. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
As far as I know, IBM did produce a mainframe with 32 bit virtual addressing. There might not be many around, and I don't think Hercules has this mode, but the 360/67 has 32 bit virtual addressing, along with BAS and BASR to use it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change in GETMAIN behavior
> From: "Tony Harminc" <t...@harminc.com> > On 19 November 2015 at 10:14, Gary Weinhold <weinh...@dkl.com> wrote: > > But you have a valid concern about vendors' assembler code. We should be > > asked whether we know about this. (snip) > One slighly related point: It has been the case from day 1 of MVS > (OS/VS2 R2) that even though GETMAIN can give out non-zeroed storage, > that storage will never contain data left over from another address > space, or from a fetch protected subpool in the current or common > space. This would be a violation of the MVS statement of system > integrity, and if found would be fixed very quickly. As far as I know, OS/360 didn't zero GETMAIN storage, and didn't guarantee that it didn't have anything left over from another job, or other task of your program. OS/VS2 R1.x was mostly MVT with VS added, though there likely were changed to GETMAIN. (As well as I know it, MVT uses GETMAIN to allocate partitions for jobs, in addition to its usual use.) -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NFS Client implementation query
In article
Re: V constants
- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, August 26, 2015 5:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: V constants Glen Hermannsfeldt wrote: I assembled: * test V constants EXTRN XXX XXX DC V(XXX+4) END with Z390. It assembled the 4 into the constant without any error or warning message. Same with the EXTRN removed, or replaced by an ENTRY statement. Can you please post the result of XREF and LIST? It would be interesting to see the resultant assembly and their offsets. A different question, is what does the linker do in this case? For A constants, the linker adds the value assembled into the constant (the offset). Where? I'm not sure what offset in what sections are you referring? I would like to compare that with Peter Relson's reply. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
V constants
I assembled: * test V constants EXTRN XXX XXX DC V(XXX+4) END with Z390. It assembled the 4 into the constant without any error or warning message. Same with the EXTRN removed, or replaced by an ENTRY statement. A different question, is what does the linker do in this case? For A constants, the linker adds the value assembled into the constant (the offset). -- glen -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Ehrman Sent: Tuesday, August 25, 2015 10:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM-MAIN Digest - 23 Aug 2015 to 24 Aug 2015 (#2015-236) On Sun, 23 Aug 2015 23:25:53 -0500 Paul Gilmartin paulgboul...@aim.com asked regarding 8-byte V-cons EXTRN EXTERNAL DCV(EXTERNAL+4) points at EXTERNAL DCA(EXTERNAL+4) points 4 bytes past EXTERNAL Why isn't the former code reported as a syntax error? (If not assembled as coded.) Has anyone tried assembling it? 8-) John Ehrman -- 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: Ideas for hash of a sequential data set
Is this the relative or absolute TTR? The MBBCCTTR will change for an exact copy. Which DSCB fields won't change for a block for block copy of the data set? -- glen -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, August 20, 2015 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ideas for hash of a sequential data set I did misunderstand you and yes, you are right, one very common change would be an append, and that would change the last TTR field and thus the DSCB hash -- as would any total rewrite that did not happen to be the same length. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Thursday, August 20, 2015 10:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ideas for hash of a sequential data set Charles, I think that you misunderstood me. I'm suggesting that the cheap first hash (used to rule out common changes) would be over a combination of: - the first n bytes of the data set (just like you suggested) - the F1/F8 DSCB (which has stuff like DS1LSTAR and DS1TRBAL which helps to detect common changes to the end -- 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: 3380 was actually FBA?
The important distinction of FBA is that block headers aren't rewritten when the data is changed. (Not counting when a low-level format is done, normally for the whole drive.) I don't know the low-level details of the 3380 to know. It might be that the 32 byte blocks are related to ECC, and are not FBA-like blocks. If block headers are not rewritten, then I would call it FBA-32 under the hood. -- glen -Original Message- (snip) Was that the first (and/or last?) IBM SLED to be inherently FBA under the hood? Where were the smarts for that implemented, in the control unit, or the drive itself? The count, key, and data field data on a native 3380 were written in 32-byte increments, but since a physical data block could be an arbitrary number of 32-byte chunks and unused 32-byte chunks at varying positions around the track had to be wasted between physical blocks for inter-block gaps, I wouldn't call this FBA-under-the-hood. The physical block size (up to 31-bytes larger than known to the Operating System) definitely wasn't Fixed, just restricted to a multiple of 32 bytes. The only fixed part of the track architecture was the 32-byte increment size. Perhaps at the actual device hardware level a 3380 could have been given the capability to randomly address, read, and write individual 32-byte track increments while using all possible 32-byte increments on the track for data, but I would expect that would have been a much more expensive design than was required to support CKD architecture. My strong impression was that the erased IBG between physical blocks was a requirement for proper sensing of beginning of a block. The requirement that some 32-byte increments must be left unused for IBGs indicates these 32-byte groupings do not play the same role as fixed data blocks in FBA architecture devices. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- 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: Limit number of frames of real storage per job
Anne Lynn Wheeler wrote apl\360 would allocate new storage for every assignment statement, quickly using every available location in workspace ... and then it would collect everything in contiguous storage (garbage collect) and then start all over again.. This wasn't too bad with apl\360 typically 16kbyte (sometimes 32kbyte) workspaces there were swapped as integral unit. the initial port of apl\360 to cp67/cms for cms\apl was something of a problem because it allowed workspaces that were the size of virtual memory ... and strategy would quickly result in page thrashing (repeatedly touching every virtual page regardless of actual programdata size). One that I have always wondered about, PL/I (F) at the end of a compile run, tells how much memory it used out of the total available. Does it find out how much is available without paging in all those pages? Seems to be something that MVT would not notice, but could be very Important on VS systems. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
The usual C malloc() keeps track of allocated memory with data just before each allocated block. As well as I understand it, GETMAIN works similarly. (snip) I believe that there have been some improvements along the way, but don't know about them. At least since MVS/XA (circa 1982), VSM control information is kept in cell pool extents located in ELSQA. In the OS/VS2 days, I had the manuals describing the way OS/360 does things like GETMAIN. Back when you could almost understand them without a lot of studying. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS stack vs heap storage
In languages where the default is automatic (PL/I and C, for example), it is usual for variables in MAIN to be automatic. The compiler compiles MAIN the same way, with a special routine that does some setup before calling actual MAIN. In the case of PL/I with multitasking, it is possible for MAIN to be reentrant. (I don't know all the details now, but pseudo-registers are used to keep track of data that is different for different tasks, and isn't on a stack or linked list.) To answer the question, in the case of multitasking you have to be careful with static variables in main. The usual implementation on OS/360 descendants is a linked list with dynamically allocated list entries as save areas, logically, but not physically, a stack. Static variables are generated using an appropriately named CSECT. Hope this helps. --glen -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, August 7, 2015 2:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS stack vs heap storage Don't want to work on a Friday afternoon, so a question for you all... I come from the VSE world where COBOL still does not have a LOCAL-STORAGE SECTION, so our code doesn't use that new feature (new within the last 20 years, I guess!). I know generally for a subroutine when you would want to use WORKING-STORAGE (heap/static) vs. LOCAL-STORAGE (automatic/stack). I am curious is there any reason you'd ever want to use LOCAL-STORAGE in a MAIN program. It looks like for PL/I the default is AUTOMATIC. I don't know if this implies anything with regard to COBOL storage types. Thanks, Frank -- 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: Limit number of frames of real storage per job
The usual C malloc() keeps track of allocated memory with data just before each allocated block. As well as I understand it, GETMAIN works similarly. As with the note about garbage collection, that tends to cause a lot of page-in references going through the linked-list of memory blocks. I believe that there have been some improvements along the way, but don't know about them. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, August 7, 2015 5:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job Would'nt the garbage collection cause page-in references as objects are collected and co-located? Thus negatively affecting performance on page sensitive (e.g. CICS) middleware/applications. Seems the advice to avoid garbage collection is sound to me (from a performance perspective). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: useless but amusing: largest known prime
Instead of a file with 57885161 C'1', I tried a file of 57885161 X'FF'.
BEGIN {
for(i=0;i57885161;i+=8) printf %c,255;
}
08/05/2015 02:02 PM 7,235,646 prime.out
08/05/2015 02:03 PM 7,046 prime.out.gz
08/05/2015 02:04 PM90 prime.out.gz.gz
and as noted, two passes through gzip.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, August 5, 2015 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: useless but amusing: largest known prime
On 2015-08-05 12:50, Gibney, David Allen,Jr wrote:
Taking 7M to store. I wonder how well that will compress :)
I decided to try something practical:
506 $
506 $ time awk 'BEGIN { for ( I = 0; I57885161; I++ ) printf( 1 )
print }' | gzip | wc
1 5 56203
real0m18.422s
user0m11.265s
sys 0m6.188s
507 $
507 $ uname -a
Linux Gil-CrunchBang-Lenovo 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u2 i686
GNU/Linux
Dismaying; barely a factor of 1000. And dumping shows obvious redundancy.
So I compressed it again (which rarely helps) and gained another factor of 200:
0 8 255
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: useless but amusing: largest known prime
8 bits per byte, all ones.
To do it right, the first should have 57885161%8 ones, but that probably doesn't
change the compression much. But okay:
BEGIN {
n=57885161;
printf %c, rshift(255,8-n%8);
for(i=1;in;i+=8) printf %c,255;
}
08/05/2015 04:01 PM 7,235,646 prime.out
08/05/2015 04:01 PM 7,047 prime.out.gz
08/05/2015 04:01 PM93 prime.out.gz.gz
Oh, yes, it should have said 7235646 bytes of X'FF',
Now it is X'01',723646X'FF'
(and the third compression increased the original from 90 to 110 bytes.)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bob Rutledge
Sent: Wednesday, August 5, 2015 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: useless but amusing: largest known prime
Why i+=8?
Bob
On 8/5/2015 5:11 PM, Glen Hermannsfeldt (Contractor) wrote:
Instead of a file with 57885161 C'1', I tried a file of 57885161 X'FF'.
BEGIN {
for(i=0;i57885161;i+=8) printf %c,255; }
08/05/2015 02:02 PM 7,235,646 prime.out
08/05/2015 02:03 PM 7,046 prime.out.gz
08/05/2015 02:04 PM90 prime.out.gz.gz
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
replacement CRTs for 3278s
Shmuel Metz , Seymour J. shmuel+ibm-m...@patriot.net wrote: In 20150730231354.cffa74874...@lara.ugcs.caltech.edu, on 07/30/2015 at 04:13 PM, glen herrmannsfeldt g...@ugcs.caltech.edu said: Does anyone know where to get replacement, either new or with lots of life left, CRTs for 3729 3279? It was supposed to say 3278 like in the subject. I thought they would have been popular enough that there would be some around. Otherwise, we haven't tried CRT rejuvenation yet. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
replacement CRTs for 3278s
Does anyone know where to get replacement, either new or with lots of life left, CRTs for 3729s? thanks. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
(snip, I wrote) From one 1403 manual, I see some gears that are specified for 50Hz and for 60Hz, but I am not sure what they do. As far as I can tell, the train is powered by a synchronous motor (or close enough). I presume you don't want the train running 1.2 times as fast. (snip, John Eells wrote) The print train (or chain, depending on model) in 1403s was direct driven. The vertical motor shaft was keyed to the print train. If the motor speed were to change, the hammer flight timing set in the 2821 control unit would be far off, resulting in the printing of partial characters at best. Whether they compensated for this with motor wiring, a different motor, or different flight timing settings, I have no idea. (The factory took care of that stuff!) I don't recall any gears in the 1403, so it would be interesting to know where any were that got changed for operation at 50Hz. Are you sure they are gears and not hydraulic unit drive belt pulleys? https://ia601603.us.archive.org/35/items/bitsavers_ibm140xSY2nd3MaintManualDec71_21919776/SY24-3395-3_1403_Models_N1_and_3_Maint_Manual_Dec71.pdf See page 31 (or 1-26). Induction motors run slightly slower (they aren't perfectly synchronous) than some integer fraction of the line frequency. At 60Hz, one might run at 3500 RPM or 1750RPM or 1150RPM (a little slip below 3600, 1800, and 1200). A 50Hz motor might run at 2900 RPM or 1450RPM or 950RPM. But it isn't hard to change the gear coupling the motor to the chain or train, such that the speed is right. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
(snip, someone wrote) I don't know power consuption, but nowadays it's not hard to get semiconductor-based power supply which generater 60Hz or 50Hz or any value you want (within some range). (snip, someone else wrote) (sorry for losing the attributions, I am copying from usenet) I suppose a 1403 requires a couple kW. That shouldn't be an obstacle: Yes, but an added complication. From one 1403 manual, I see some gears that are specified for 50Hz and for 60Hz, but I am not sure what they do. As far as I can tell, the train is powered by a synchronous motor (or close enough). I presume you don't want the train running 1.2 times as fast. I suspect that only synchronous motors need to run off a power converter, which would allow for a smaller converter, but more complication in wiring. https://en.wikipedia.org/wiki/High-voltage_direct_current CDC equipment circa 1970 used 400 Hz with rotating mechanical converters. As I understood it at the time, larger S/360 and S/370 also used motor-generator power supplies, though I don't know the output frequency. The higher frequency means less filtering. But yes, you can run a CDC machine off an electronic converter. Provided considerable immunity to power surges. Flywheels? -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
1403 at 60Hz
I wonder if anyone knows what has to change to move a 1403 from 50Hz to 60Hz? If they use synchronous motors, then some belts or gears would be different. For transformers, you need more iron in the core for 50Hz, so 50Hz transformers should be fine at 60Hz, but not always the other way around. That might also be true for motors, but synchronous motors will run faster. thanks, -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange 047 abend
Is the EXECUTE instruction broken on your machine? With what you are doing, you could possibly cause ABEND047 (or all sorts of other abends) not on the STC instruction, but on the AP instruction, if you had set a breakpoint on the AP under TSO TEST. That could happen because you would be changing the SVC number in the SVC instruction that replaces the first two bytes of the AP for the breakpoint. That could certainly cause some head-scratching. And what does TSO TEST do if you EXecute a breakpoint SVC? It would seem an interesting case for it to get right. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3705
William Jones bjo...@followup-to-newsgroup.com wrote: (snip, I wrote) I am hoping to run Wylbur, Milten, and Orvyl, but TSO or VM/CMS are also possibilities. Is Wylbur or SuperWylbur available? I saw discussion on this years ago from Gerhard when he mentioned he was working on it but then nothing. I am not particularly interested in the source code unless that is how it was distributed. A plain IEBCOPY install would be wonderful. Yes, Stanford Wylbur and Orvyl (and all the rest) are available as open source on the Stanford web site. It will probably take a little work to get running. For one, the terminal interface might be different for different systems. Also, I believe Stanford moved away from the Susan SVC for communication between the subsystems, but that might be needed again for MVS3.8. Also, the job submission, hold, fetch, and release might be JES dependent in some way. For submission, I presume just write to an internal reader. The rest require closer interaction with JES. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3705
William Jones bjo...@followup-to-newsgroup.com wrote: On 2015-07-22, glen herrmannsfeldt g...@ugcs.caltech.edu wrote: William Jones bjo...@followup-to-newsgroup.com wrote: (snip, I wrote) I am hoping to run Wylbur, Milten, and Orvyl, but TSO or VM/CMS are also possibilities. Is Wylbur or SuperWylbur available? I saw discussion on this years ago from Gerhard when he mentioned he was working on it but then nothing. Wylbur originated at Stanford, then to NIH, then to some other places, including SLAC. Later, SLAC ran the later versions of Stanford Wylbur/370 and Orvyl/370. I believe SuperWylbur is a commercial product, derived from one of the others. (snip) Yes, Stanford Wylbur and Orvyl (and all the rest) are available as open source on the Stanford web site. I used SuperWylbur in the 1970s but did not realize it came from Stanford or perhaps I simply forgot. I thought it was a proprietary product. This is very good news. I wonder if Gerhard is aware of it. I follow most of the IBM lists but very seldom post. I believe his comments about this were on one of the Hercules lists a few years ago. Also, I believe Stanford moved away from the Susan SVC for communication between the subsystems, but that might be needed again for MVS3.8. I am not familiar with that but thanks for noting it. If I try to get this going I'll have to look it up. If the source isn't available it should be possible to reconstruct the SVC as long as the specs are available somewhere. I believe the source is there, just put all the parts together. Also, the job submission, hold, fetch, and release might be JES dependent in some way. For submission, I presume just write to an internal reader. The rest require closer interaction with JES. Yes. My recollection is so hazy to the point I remember little aside from the name and the fact it allowed us to use terminals to edit and submit jobs before ISPF was available. But more than that I cannot recall. I suspect you would be right about the JES or possibly HASP interface. Yet, I believe it was running on something very close to the 3.8J system so perhaps it will just work. SLAC had Wylbur running with ASP, which became JES3. I believe the Stanford campus ran with HASP and/or JES2. I don't know at all how that works, but hopefully the code is there and the manuals are available. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3705
http://www.livingcomputermuseum.org/About-Us/What-is-Living-Computer-Museum.aspx -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3705
Shmuel Metz , Seymour J. shmuel+ibm-m...@patriot.net wrote: (snip, I wrote) To connect terminals to a 3705. That's *WHAT*, not *WHY*. Why real terminals and why through a 3705? Probably some real terminals, and a terminal server for people not close enough. https://en.wikipedia.org/wiki/George_Mallory Mallory is famously quoted as having replied to the question Why do you want to climb Mount Everest? with the retort Because it's there, I think that is as close as I know to the reason to run a real 3705. Because it is there. Yes one can run emulated programs on an emulated host with emulated terminals connected to an emulated 3705. But it isn't the same. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3705
Shmuel Metz , Seymour J. shmuel+ibm-m...@patriot.net wrote: In 20150721061350.bb5994874...@lara.ugcs.caltech.edu, on 07/20/2015 (snip, I wrote) OK, I forgot that the Usenet gateway doesn't work anymore. I am wondering what software one needs for a 3705 to connect up ordinary ASCII terminals. NTO. Why? To connect terminals to a 3705. Well, maybe a terminal server instead of terminals. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3705
(snip, I wrote) To connect terminals to a 3705. Well, maybe a terminal server instead of terminals. I'm posting to Usenet. (Can't be bothered.) That is where I read it, so fine with me. A display? Do you intend to use ISPF, CMS? You need to provide better info. I am hoping to run Wylbur, Milten, and Orvyl, but TSO or VM/CMS are also possibilities. We might also be interested in RJE, if the 3705 can do that. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
3705
OK, I forgot that the Usenet gateway doesn't work anymore. I am wondering what software one needs for a 3705 to connect up ordinary ASCII terminals. For example, what would be needed to use TSO or Wylbur on ASCII terminals? I know this is what was done 35 years ago, but I don't know now who knows how to do it. I do remember that for dial-up lines it would allow for 300 baud or 110 baud, or even for 2741s, depending on the first character you typed. Hardwired lines were fixed speed, and could be higher than 300. (I believe O for 300 baud, and S for 110 baud.) Faster lines might only be at a fixed baud rate. thanks, -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPG for the 360/20
In article of4a881d2e.1388e6c9-on48257e66.00179ed9-48257e66.001c4...@sg.ibm.com you wrote: (snip) As for where you'd obtain any of these compilers (except obviously 5740-RG1), I'm not sure. You could try the roughly five organizations that have actual Model 20 machines in their collections. They include the Living Computer Museum in Seattle, the Computer History Museum in Mountain View (California), and the Deutsches Museum in Munich, as examples. IBM Research in Boeblingen, Germany, also apparently has a Model 20 on display, and (allegedly) it's a working model -- though I have no direct knowledge of that. You could also try asking W. Van Snyder at NASA's JPL who (it seems) has also been trying to track down these older compilers. I am at the Living Computer Museum, which is why I am interested in one. I asked Boeblingen people, and they don't have it. I think they would also be interested if I found one. Definitely their machine runs, at least some of the time. Many compilers require disk or tape, which we don't have. I am wondering about someone with card trays left over from years ago. thanks, -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RPG for the 360/20
Just wondering, does anyone know where a copy of the RPG compiler for the 360/20 is? Presumably on cards, but maybe some other form. Other 360/20 software could also be useful, but mostly if it doesn't need disk or tape. thanks, -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
In article 09a301d098e6$0607d120$12177360$@mcn.org you wrote:
(snip)
I have isolated the ABEND to a call to a self-written assembler function
called ISAUTH. I execute a printf() immediately before the call but not a
printf() after. I am posting below the entire code of ISAUTH. CDSALEN has a
value of x'60C'. I think other than that the code snippet is self-contained.
(snip)
It used to work. What changed? I added some functions and the module grew to
have addressability problems, so I added an IEABRCX DEFINE. I have eyeballed
the code generated by EDCPRLG and it appears correct -- now with a BRC 15
instead of a B. It would be inconvenient to get the IEABRCX back out of
there as a test.
Can you post the expansions of EDCPRLG and EDCEPIL?
I presume they do save and restoring of registers, and appropriate
save area linkage, but it would be nice to see the expansion.
The function is declared in C++ as extern OS {bool ISAUTH();}. The other
functions are declared similarly.
AMODE 31/XPLINK(NO)
Does anyone have any clues?
ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG=NONE
LARL R12,CZAMISC
USING CZAMISC,R12
*
* *** USING CDSASTOR,R13 Use R13 as base for reentrant store
*
* Issue the TESTAUTH
TESTAUTH FCTN=1
*
* TESTAUTH returns 0 = yes, 4 = no
* We return 1 = yes, 0 = no
SRL R15,2 Convert 4 into 1
LCR R15,R15 Convert 1 into -1
AHI R15,1 Convert 1 into 0 and 0 into 1
*
* *** J Ret_R15Return whatever is in R15
EDCEPIL ,
-- glen
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Odd directory in /SYSTEM/var/
Directory name contains string .Ýd What does it mean? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Odd directory in /SYSTEM/var/
EUID=0 /SYSTEM/var/.ÝD.ÝD.ÝD.ÝD.ÝD.ÝD.ÝC.ÝC.ÝC.ÝC.ÝC.ÝC.ÝC.ÝC.ÝC.ÝC.ÝD.ÝD.ÝD Type Perm Changed-CST6CDT --Size Filename Row 1 of 5 _ Dir755 2014-11-02 12:298192 . _ Dir777 2014-11-02 13:588192 .. _ Dir755 2014-11-02 12:298192 clientmqueue _ Dir755 2014-11-02 12:298192 cron _ Dir755 2014-11-02 12:298192 mqueue -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C compiler substituting for macros inside literals?
Charles Mills write: #define V 5 #define STRINGZ(a,b,c,d) printf(%d %s %s %s %s\n, V, #a, #b, #c, #d) STRINGZ(The, quick, brown, fox); the compiler is making of it printf(%fox %s %s %s %s\n, 5, The, quick, brown, fox); As I understand it, this is usual for the pre-ANSI preprocessor. Well, not quite as pre-ANSI the # stringizing operator didn't exist, but since it did substitute inside quotes, you didn't always need it. Newer compilers will do this with the -traditional option. Many compilers now do the preprocessing as part of the compilation, instead of as a separate step with intemediate file, as was done traditionally. Also, the traditional (not ANSI) preprocessor is often used with Fortran, and some other languages (such as make) that don't work with the ANSI version. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OPEN not filling in DCBBLKSI for RECFM=U data set
Paul wrote: IBM designers a half century ago are not to be forgiven for the continuing anguish they inflicted on programmers in order to save two bytes in the DCB. There should have been two separate fields, one for the label block size; the other for the size of the block currently being processed. As explained in Mythical Man Month, programmers had byte budgets when writing OS/360. It had to be able to fit, even on the smaller systems. For example, I learned, painfully, that to write a short block with BSAM at the end of a RECFM=FB data set, I need to set DCBBLKSI to the length of that block. I did, and my data set was unreadable. I was astonished and dismayed to learn that value was copied to the DSCB on CLOSE. I needed to save and restore it, wasting far more storage than a distinct halfword in the DCB would have spent. OK, but the code for doing OPEN and CLOSE can easily be in an overlay, and so doesn't take up space during normal processing. Even more, on the smaller systems I/O was unblocked (because you couldn't afford the memory for a larger buffer) and so there was no need to change DCBBLKSI as it was always DCBLRECL even on the last block. The overhead to save and restore only occurs on larger systems. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XR vs SR
David Bond wrote: Anyone who thinks that the S/360 instruction timings have any relevance to how machines work today has no understanding of the last several decades of processor design. Yes, simple instructions generally execute faster than more complex instructions. But even that rule of thumb is overshadowed by pipeline stalls caused by register dependencies, Address Generation Interlock, address translation, cache effects, branch prediction and other things. Yes, but the S/360 timings are the only ones we have. In the specific case or XR vs SR, both are the same speed on probably any machine since 1975. But neither can be faster than LHI because XR and SR set the condition code and LHI does not. Setting the condition code is a separate suboperation. I used to know how the 360/91 did some of this. I am not sure by now how it did register renaming, and the condition code complicates it, but I think if the condition code is set soon after, before any instruction that tests it, the processor can avoid that problem. The 91 could be much more aggressive in reordering instructions, is it didn't have to worry about page faults. The difference in the length of XR and SR vs LHI does not make up for the fact that XR and SR are more complex than LHI. Furthermore if i-cache has any measurable effect, then alignment or misalignment of blocks of instructions to i-cache boundaries will almost always have a bigger effect than individual instruction length. (big snip) If someone really wanted to know the specifics of some instruction use timing, one could take a complex benchmark, such as some of the SPEC programs, Carefully compile it twice, such that one, for example used XR and the other SR to clear registers, then time the difference. Do it a few times to make sure that the difference was reasonably statistically significant. With enough different runs of different programs, one could compute the statistical average execution time for each instruction in actual programs. Hopefully it would average over cache misses. Pipeline stalls probably shouldn't average out, as you want the proper statistical cost in actual use. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XR vs SR
Robin wrote: XR Rn,Rn is faster than SR. But does it matter? Who says that XR is faster than SR? I know the IBM OS/360 software and compilers generate SR instead of XR. From: http://bitsavers.trailing-edge.com/pdf/ibm/360/A22_6825-1_360instrTiming.pdf on many S/360 models SR was much faster than XR, equal on the 2040, and not slower on any. Do you have any timings for high-end S/370 or later models? (With instruction overlap, it is pretty much impossible to give single instruction timings on many models.) Since IBM software assumes SR is faster, they would have a reason to special-case it on any later models, but maybe not XR. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
BCT or BCTR
Someone wrote: And you can use BCTR to save a few µS. Why do you think BCTR would save such a large amount of time? Perhaps you're again talking about old machines. Surely BRCT/JCT would be the time saver on a current machine if there is one for this case. Yes, he must have been thinking about an old machine, specifically the 360/40. It is about 5 microseconds on the 360/30. Interestingly, BCT is faster than BCTR on the 360/50 and up. Newer machines with branch prediction will normally predict the branch as taken, and the time will be independent of which form is used, except possibly for the first time. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data flow for 1403-N1?
From GA24-3073-8_1403_printer.pdf on bitsavers, in figure 4, it looks like 48 train characters align with 132 print positions, and gcd(132,48) = 12 chain characters, or every 11th print position, can be aligned at once. (Chain printers are all except 3 and N1.) The formula on page 27 indicate that it takes about 240*0.000729s, or 0.175s for the train to go around in the N1, and 240*0.001665s, or 0.400s on the chain printers. With 240 characters, those are 729us and 1665us for the chain/train to move one chain/train character position, or to move 132/48 print character positions. As noted above, every 11th print position is aligned at once, so 1/11 of that between hammer firing positions. So, for the non-N1 1665us*48/132/11 or 55us, and, assuming the other numbers are the same, 729us*48/132/11 or 24us for the N1. The character print speed on the N1 and 3 is about twice as fast as the other models. I don't see anything saying that the spacing of the characters on the train and chain printers is different. Every 11th print position for simultaneous firing sounds closer to what I remembered, and makes it easier to build power supplies (which have to supply peak current). It only takes a small shift in the spacing, though, for a very different value. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Hijacking User SVC ABEND code S048
Someone wrote: An abend from SVC 248 would be FF8, not 0F8, user or not. I used to see FFE abends from time to time in a prior shop, and it was from one of our IMS or ISV SVCs (can't remember which now), which happened to be 254 (FE). 0F8 is an abend in Supervisor control, IEAVESVC, and is for the reason documented in System Codes, as Tom Marchant included in a prior response. As well as I remember, the SFxx codes are when an SVC is issued and no SVC routine is there to service it. I believe that is true for IBM range and User range, but at least user range. Now, what is SVC X'22' where the ABEND codes like 322 come from? -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL packed decimal
(John Gilmore wrote) A little presumptuously perhaps, I shall reply for 'someone' He or she would appear to be a soul mate. The remark about floating-point that Mr Hermannsfeldt attributes to Knuth are relevant to HFP and, perhaps, BFP. Their timing moots any relevance to Cowlishaw's DFP. Well, the remark, as far as I know, was intended to be general, and at the time there were many different floating point systems in use. Moreover, they arev not relevant to it: it uses decimal digits, sand Mr Hermamnnsfeldt's post does not petray any acquaintance with it. I have followed it since before 2008, a few times posted (maybe in other groups) that I believe it is a good idea. It should reduce, for example, the number if people who find that (1./3.)*3. is not 1.0, and in fact truncates to zero. The rest of Mr Hermannsfeldt's is also less than confidence-inspiring. Consider, begin extract The period of the earth's orbit is 365.256363004 days, or known to about 1 part in ten to the 11th. /end extract Now there are many measurements and calendrical definitions of the period of the earth's orbit. The measurements most widely used are those for the mean tropical year, the time between successive vernal equinoxes. Its current value is 365.2421_9668, but its precision is an elusive notion because its value is known to be dropping. That is true, but the point being that once one does define an appropriate year it is possible to measure it with an amazing degree of precision. Even so, smaller times, such as the period of optical frequencies, can be measured with a much smaller absolute uncertainty, though similar relative uncertainty. There are many physical quantities that can be measured with approximately the same relative uncertainty over a wide range of magnitudes. For those quantities, floating point is especially useful, as it allows for computations of quantities derived from those, giving reasonable relative uncertainties. For example, if one measures a length and time with 1e-8 relative uncertainty, then one can compute a velocity with about 1.4e-8 relative uncertainty. (That is, sqrt(2)*1e-8.) That is true for nm to Mm scale, maybe fm to Em. Actually, time can be measured with an absolute uncertainty over a fairly wide range, but often only a relative uncertainty is needed. Now one of the major differences between the old Julian calendar, which has a mean year length during its four-year cycles of 365.25 days, and the 'new' Gregorian calendar, which has a mean year length of 365.2425 days during its 400-year cycles, is just their very different leap-year rules, which give rise to these differences. Mr Hermannsfeldt's number suggests that the Julian calendar is better at handling precession than the Gregorian one, but this is not the professional consensus. There was no such intention. It was meant as one example of a quantity that could be measured with an amazingly small relative uncertainty. Now, TeX does all its typesetting calculations in 32 bit with 16 bits after the binary point. (That is, the unit is 1/65536 of a US printers point, which is 1/72.27 of on inch.) That allows for resolution smaller than the wavelength of visible light, up to about 37 feet or 11.5m. (If you need something bigger, you can just scale it during printing.) Typesetting tends to have an absolute error based on printing device resolution. Floating point at 32 bits would not be so useful. One could go to 64 bit float (in any base), but would still have to watch rounding. More important, no rounding problems occur. Fixed point division always truncates (at least for positive quantities) and a remainder is supplied (when needed). Now, it is true that DFP helps with some of those problems, but when programming in a high-level language one generally doesn't know what kind of floating point will be used. Some, like HFP, give a truncated quotient on divide (except on the 360/91), others a rounded result. If you want identical results on all systems, you have to be very careful with rounding modes. (Even if you know its DFP, you might not be able to set the rounding mode.) Note also that one is not so likely to use typesetting at the fm (femtometer) or EM (exameter) scale. (The atomic nucleus is about one femtometer, also called the Fermi, in diameter.) Others can comment on financial calculations better than I can. E. B. White said long ago that people who like the word 'personalize' should of course be free to use it but not perhaps to teach others to do so. My view of Mr Hermannsfeldt's views on floating-point arithmetic is of a piece. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Decimal arithmetic
(someone wrote) Some years ago this situation changed dramatically. Mike Cowlishaw---he who designed REXX---devised what is now ANSI decimal floating point (DFP). DFP behaves consistently in ways that do not surprise accountants. (All three floating-point formats are supported by zArchitecture hardware.) According to D.E.Knuth, there are two things that should not be done in floating point: financial calculations and typesetting. Floating point is great for quantities with a relative error. That is, where the uncertainty in measurement scales with the value. One can measure lengths in nanometers or gigameters to about one part in 100 million or so at best(*) For quantities where the uncertainty does not depend on the magnitude, fixed point is a better choice. I expect my bank to keep my balance to the cent, when I have either $1.00 or (rarely) $1,000,000.00 in my account. Digital typesetting needs to be able to position glyphs on the page consistently. The eye is amazingly sensitive to some types of positioning errors. Knuth has an example of a typesetting machine that was thought to have 5333 dot/inch resolution, but turned out to be 5333 and a third dpi. The difference was visible in printed output. TeX and Metafont use only fixed point arithmetic for any calculation that affects the printed page. Some messages to the user use floating point arithmetic. Although there has been ample tIme to do so, IBM COBOL does not yet support DFP. It should. When IBM COBOL does support DFP, it will be possible to eliminate packed-decimal (except as a transitional data type in certain conversion operations) from COBOL routines; and doing so will confer large performance advantages. I suppose if one is careful in how it is used. Still, the 15 decimal digits from S/360 packed decimal should be enough for most uses. (31 digits for add/subtract.) -- (*) (The lattice constant for crystalline Silicon is 543.102 0504 x 10^-12 m with a relative error of 1.6 in 100,000,000.) The radius of the earth is about 6371km. Because the earth isn't a perfect sphere it is hard to give it much more accurately, though one could measure the distance between two points on the earth more accurately. The semi-major axis of the earth's orbit is 149598261km, so again to about one part in 100,000,000. The period of the earth's orbit is 365.256363004 days, or known to about 1 part in ten to the 11th. Optical spectra lines can also be measured to a similar relative uncertainty. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
