Re: Dynalloc (was Macro processor)

[Michael Stack]

Walt, you wrote, "Therefore, RACF is not allowing an ENQ on a DSN, because RACF 
has no idea that an ENQ is being done." and it occurs to me to point out that, 
likewise, ENQ is not preventing access to a DSN because ENQ has no idea that a 
dsn is being accessed (which, of course, is different from a data file being 
accessed).

What a marvel these semaphores are; examples abound, without us ever thinking 
"semaphore."

Mike

At 02:58 PM 12/24/2017, you wrote:

>On Sun, 24 Dec 2017 12:17:22 -0700, Paul Gilmartin  
>wrote:
>
>>On 2017-12-24, at 11:01:38, Farley, Peter x23353 wrote:
>>> 
>>> If truly a DOS attempt, then this would be followed the next day by 
>>> promotion to the street for the responsible programmer and reprimands for 
>>> the code reviewer(s) for missing such a trick.
>>>  
>>But the DoS could be inadvertent, by a novice programmer, unprivileged,
>>outside the production stream, not subject to review.
>>
>>And for this, DYNALLOC provides somewhat better protection than JCL
>>because such a person would probably lack S99WTDSN authority.
>>
>>It's a pity that RACF allows ENQ on a DSN with no authority to
>>access that data set.  But that would require that JCL distinguish
>>between intent to write and not to write, and more.
>
>I have to be pedantic here and point out RACF does not allow or prevent access 
>to anything, gil, except its own resources. RACF for the most part merely 
>answers security questions asked by others, and they are the ones that allow 
>or deny access.
>
>Therefore, RACF is not allowing an ENQ on a DSN, because RACF has no idea that 
>an ENQ is being done. If anyone were to control that, it would be data set 
>allocation, who would have to invoke RACF to ask if the user would have 
>authority to eventually OPEN the data set.
>
>(And, by the way, it's a difficult question for RACF to answer or more 
>properly for allocation to ask, for several reasons. Among them, the 
>possibility of discrete profiles means that until the data set is allocated so 
>the DSCB can be read, allocation doesn't have all the necessary information to 
>pass to RACF.)
>
>-- 
>Walt

Re: Any real need for sequence numbers in 73-80 any more?

[Michael Stack]

At 09:25 AM 12/11/2017, you wrote:
>In VM-land, they're canon, because of use of CMS UPDATE for maintenance. z/OS 
>is poorer for lack of an equivalent: I know there's IEBUPDTE, but with no good 
>way to create updates, it doesn't seem to be used much. XEDIT in UPDATE mode 
>makes source maintenance SO much easier! A shame that functionality never got 
>added to ISPF.
>
>...phsiii

For many years, I used a program called IEBUPDTX to do something similar to CMS 
UPDATE but in OS. It's available on the CBT tape as file CBT957.

Mike 

Re: Detection of Compile-Time Self-Modifying Code

[Michael Stack]

That would surely be nice, Ed, but there are so many possibilities for 
circumvention of any such "solution" that I would be skeptic No 1. (And I 
haven't thought about nastiness like this in YEARS!).

Mike

At 11:21 PM 10/9/2017, you wrote:

>Like most ISVs writing HLASM code, we use OPTABLE to ensure our programmers 
>don't accidentally use instructions that aren't available on older machines 
>that we must still support.
>
>Currently, we're using OPTABLE(YOP) because our minimum supported OS is z/OS 
>1.12. (It's not until z/OS 2.1 that we can leap ahead to the z9 machines.)
>
>We recently terminated a reckless/destructive/rogue/cowboy programmer who 
>would routinely and subversively insert "land mines" into our code without 
>anyone knowing. Someone found another one this week:
>
>|DO UNTIL=NO   Until all chars processed
>|  * Until we break free from OPTABLE(YOP), the ORG game must be used
>|  TROT  R14,R2  Convert to hex
>|  ORG   *-2 ORG back to set M3 field
>|  DCX'10'   M3 = 1 to suppress stopper
>|  ORG   ,   ORG back
>|ENDDO ,   EndDo TROT
>
>Obviously, the right way to code this would have been to use ACONTROL OPTABLE 
>with surrounding PUSH/POP to get the newer TROT function. But, doing so could 
>raise the visibility of the sabotage to the level where someone might notice. 
>So, he chose to alter the instruction via ORG/DC. (IMHO, ORGing back to change 
>an instruction is a form of self-modifying code, which we don't allow.)
>
>It might be nice if the assembler could generate an error or warning message 
>if an instruction is modified at compile time.
>
>Thoughts?
>
>-- 
>Phoenix Software International
>Edward E. Jaffe
>831 Parkview Drive North
>El Segundo, CA 90245
>http://www.phoenixsoftware.com/

Re: superior IBM supplied "register equate" macro?

[Michael Stack]

It makes a fine introduction to macro language programming (iteration) for 
assembler students, so add another count for each of those.

Mike

At 03:05 PM 7/20/2017, you wrote:

>Makes sense, I think.
>
>I would guess that about 10,000 programmers and/or shops (literally) have done 
>their own.
>
>Charles
>
>
>-Original Message-
>From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
>Behalf Of John McKown
>Sent: Thursday, July 20, 2017 11:52 AM
>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>Subject: superior IBM supplied "register equate" macro?
>
>I know about YREGS and IAZYREG. But there are not what I want. What I want 
>would have lines akin to:
>
>R0   EQU   0GR
>R0_64EQU   0GR64
>R0_32EQU   0GR32
>AR0  EQU   0AR
>
>
>​Am I just being "too anal" in wanting to have something flagged like:
>
>MVI SOMEVAR,R0 SAVE HIGH BYTE OF R0 IN STORAGE
>* ABOVE COMMENT IS OBVIOUSLY DONE BY A ROOKIE
>
>or
>
>LG R0,DOUBLEWORD​
>
>
>--
>Veni, Vidi, VISA: I came, I saw, I did a little shopping.
>
>Maranatha! <><
>John McKown

Re: converting character to packed

[Michael Stack]

True, Tony - this solution was for a fixed format.

At 09:14 AM 10/18/2016, you wrote:
>Michael,
>
>There are inherent problems with using TR. The following are examples of valid 
>input that has to be handled correctly. I have used the "^" character to 
>indicate blanks.
>$1,000.00^
>1,000.00^^
>+1,000.00^
>-1,000.00^
>1,000.00-^
>^^^1000.00
>1000^^
>1000.0
>1000.000^^
>
>Properly identifying the decimal place and the number of trailing digits is 
>critical before the data is stored in a packed field and it can not be handled 
>by any simple TR instruction.
>
>Sign identification can also be an issue since there is no standard of putting 
>it first or last.
>
>(And as others have said, the TR and TRT instruction are cpu hogs when 
>compared to a simple loop though the data.)
>
>
>Tony Thigpen
>
>Michael Stack wrote on 10/18/2016 09:59 AM:
>>This is by far the easiest, if not the simplest, solution. There was, once 
>>upon a time, an example in an IBM pub, but for the life of me, I cannot 
>>recall where. Still, one TR will do it; create a result field whose bytes are 
>>indexes into the source value treated as a TR table such that only the 
>>numeric values are selected. Easy. Thanks for reminding me, Robin.
>>
>>Mike
>>
>>At 01:34 AM 10/18/2016, you wrote:
>>
>>>Using TR in a different way omits the commas and decimal point, sign,
>>>and any other funny characters.
>>>To do this, you swap the roles of the translate table and the string
>>>being translated.
>>>
>>>- Original Message -
>>>From: "IBM Mainframe Assembler List"
>>>To:
>>>Cc:
>>>Sent:Mon, 17 Oct 2016 16:24:18 -0400
>>>Subject:Re: converting character to packed
>>>
>>>The TR command would leave all the non-numeric characters in the
>>>data, translated as you specified, so you'd have to have a technique
>>>to pass through the result to remove them. A TRT instruction would
>>>help you find the non-numeric characters, but in this case it would be
>>>considerably slower in execution than the character by character loop
>>>approaches suggested.
>>>
>>>If the original manually-entered data is not edited as it's entered,
>>>there could be many other characters besides "$",",","." and EBCDIC
>>>numeric characters in it. That's something TRT could check for.
>>>
>>>Gary Weinhold
>>>Senior Application Architect
>>>
>>>__
>>>
>>>On 2016-10-17 15:11, robi...@dodo.com.au wrote:
>>>
>>>Won't a TR followed by a PACK do this?
>>>Email sent using Dodo Webmail
>>

Re: converting character to packed

[Michael Stack]

This is by far the easiest, if not the simplest, solution. There was, once upon 
a time, an example in an IBM pub, but for the life of me, I cannot recall 
where. Still, one TR will do it; create a result field whose bytes are indexes 
into the source value treated as a TR table such that only the numeric values 
are selected. Easy. Thanks for reminding me, Robin.

Mike

At 01:34 AM 10/18/2016, you wrote:

>Using TR in a different way omits the commas and decimal point, sign,
>and any other funny characters. 
>To do this, you swap the roles of the translate table and the string
>being translated.
>
>- Original Message -
>From: "IBM Mainframe Assembler List" 
>To:
>Cc:
>Sent:Mon, 17 Oct 2016 16:24:18 -0400
>Subject:Re: converting character to packed
>
> The TR command would leave all the non-numeric characters in the
>data, translated as you specified, so you'd have to have a technique
>to pass through the result to remove them. A TRT instruction would
>help you find the non-numeric characters, but in this case it would be
>considerably slower in execution than the character by character loop
>approaches suggested.
>
> If the original manually-entered data is not edited as it's entered,
>there could be many other characters besides "$",",","." and EBCDIC
>numeric characters in it. That's something TRT could check for.
>
> Gary Weinhold
> Senior Application Architect
>
> __
>
> On 2016-10-17 15:11, robi...@dodo.com.au wrote:
>
> Won't a TR followed by a PACK do this?
>Email sent using Dodo Webmail

Re: My assembler text v2.00

[Michael Stack]

And is Teneke prepared to have you home all day, day after day, week after 
week, ...?? :-)

Mike

At 06:42 PM 4/13/2016, you wrote:
>...
>
>I'll be retiring from IBM at the end of May, ... .
>
>...
>Regards... John 
>-
>555 Bailey Ave, San Jose CA 95141 USA
>+1-408-463-3543  ehr...@us.ibm.com

Assembler Boot Camp at SHARE Academy in San Antonio

[Michael Stack]

I'm pleased to announce that the original, award-winning Assembler Boot Camp is 
returning to SHARE as part of the SHARE Academy.  The SHARE meeting will be in 
San Antonio from February 28 - March 4, 2016. The SHARE Academy, including the 
Assembler Boot Camp, will be held on a single day, Sunday,  February  28, 2016.

More early information can be found at http://www.share.org/academy . If you 
have programmers in your shop who, for example, need to maintain z/OS exits in 
assembler, this is an opportunity for them to acquire the basic groundwork 
toward that end. The ABC is focused on providing a fundamental understanding, 
so that the attendees will be capable of extending their knowledge 
independently.

On a personal note, I couldn't be more pleased to return to my favorite topic, 
along with my very favorite co-instructor, John Ehrman, the "father" of the 
High Level Assembler. I last presented the ABC in 2009 (I'm retired, doncha 
know), and adjusting to giving all the sessions in one day - and with 
widescreen slides! - has been a nice challenge. All of us look forward to 
teaching hungry young minds (!), so please pass this announcement along to 
anyone you believe may be interested.

All the best, and Happy New Year!
Mike


Michael Stack
http://www.kcats.org
 
"Time flies like an arrow. Fruit flies like a banana."
  Marx  

Re: 360/20 instructions

[Michael Stack]

We used to do that on our 360/67 (read dials into memory during IPL) until we 
got a machine check for a storage error (dusty contacts IIRC).

Mike

At 03:44 PM 5/25/2015 -0400, you wrote:

>You might also like to know of an undocumented instruction specific to the 
>360/20.
>This was a form of the Diagnose (opcode X'83') which allowed me to read the 
>hex dials
>on the console into storage.
>
>This was extremely useful as I had the job of converting 1401 Autocoder into 
>360/20 Assembler
>and this instruction enabled me to replace the sense switches. 
>
>On later machines under DOS I used the UPSI card.
>
>Forgive me, but it's 50 years since I coded one of those and I can't remember 
>the operand, but
>I'm sure someone will.

Re: Redesigning the Principles of Operation Manual

[Michael Stack]

Correctness is the most important, and most difficult to achieve, 
characteristic of PoO.

An example: in my nine-years-old e-copy of PoO, there is in Appendix A a 
section on sorting instructions (p. A-52 in my edition). The headers and first 
sentence read:


Sorting Instructions

Tree Format

Two instructions, COMPARE AND  FORM  CODEWORD and UPDATE TREE, refer to a tree 
— a data structure with a specific format.


The problem is that execution of CFC has nothing directly to do with trees, and 
anyone attempting to understand those instructions will be seriously misled. 
What follows is a pretty-much-accurate description of how trees are used in the 
sort assist, but comprehensibility is sacrificed.  (I should say that Dan knows 
of my concern, and this may well have been corrected in later editions.)

This comment is intended solely to point out how much more difficult it is to 
write accurate mainframe technical language today than it was fifty years ago.

Mike

At 12:09 PM 11/14/2014 -0500, you wrote:
>On 2014-11-13 20:28, Tony Thigpen wrote:
>>Something for an intern
>
>I assume this was tongue in cheek!
>
>The most important attribute of POps is correctness. No offense meant to 
>interns, but I suspect that correctness would suffer if the POps was turned 
>over to interns.
>
>--
>
>Regards, Gord Tomlin
>Action Software International
>(a division of Mazda Computer Corporation)
>Tel: (905) 470-7113, Fax: (905) 470-6507

Re: Defunct? (Was: ASSEMBLER-LIST Digest)

[Michael Stack]

ROFLMAO!

Mike

At 12:10 PM 10/1/2014 -0400, you wrote:
>...
>
>Our subject here is not defunct in either sense; but it is probably
>better that those who think it is not be disabused of their error.
>They will do less harm preoccupying themselves with RPG II.
>
>John Gilmore, Ashland, MA 01721 - USA

Re: test message

[Michael Stack]

I keep hoping to find a replacement, but I can find nothing with the facilities 
of Eudora. So, I plod on ...

Michael

At 07:15 PM 2/20/2014 +, you wrote:
>Content-Transfer-Encoding: base64Michael:
>
>
>I have used Eudora in awhile, wow ..thank you
>
>
>Regards,
>
>Scott
>
>
>
>
>
>
>
>
>
>
>
>From: Michael Stack
>Sent: ‎Thursday‎, ‎February‎ ‎20‎, ‎2014 ‎7‎:‎46‎ ‎AM
>To: IBM Mainframe Assembler List
>
>
>
>
>
>Scott, here is how it looks from Eudora (which hasn't had maintenance for many 
>years, and has no idea how to handle some code pages):
>
>At 05:05 PM 2/20/2014 +, you wrote:
>Û۝[U˜[œÙ™\‹Q[˜ÛÙ[™Îˆbase64guys is this message better and not 
>base-64-encoded 0ภ«B”X\ÙH]YHۛÝËBƒBƒB”™YØ\™ËB€Ð¡M¼tt

Re: test message

[Michael Stack]

Scott, here is how it looks from Eudora (which hasn't had maintenance for many 
years, and has no idea how to handle some code pages):

At 05:05 PM 2/20/2014 +, you wrote:
>Content-Transfer-Encoding: base64guys is this message better and not 
>base-64-encoded ?€
>Please let me know,,,
>
>
>Regards,
>
>Scott

Re: TRTE, etc.

[Michael Stack]

I wish I could help, but this is the closest I could come:

"The recognition of the insuperable limits to his knowledge ought indeed to 
teach the student of society a lesson of humility which should guard him 
against becoming an accomplice in men's fatal striving to control society - a 
striving which makes him not only a tyrant over his fellows, but which may well 
make him the destroyer of a civilization which no brain has designed but which 
has grown from the free efforts of millions of individuals."

F. A. Hayek, The Pretense of Knowledge

Mike

At 07:44 PM 4/18/2013 -0500, you wrote:
>I would love to add the citation for the following quote, which I immediately 
>glommed upon sight for my FB Favorite Quotations.  Mr. Gilmore?  Anyone?  In 
>any event, it somehow seems apropos.
>
>Watching people who do not recognize the limitations of their experience 
>pontificate about what the rest of us should do can be a source of amusement, 
>if you can get past the annoyance. ~ anon.
>
>
>Am 18.04.2013 20:53, schrieb Andreas F. Geissbuehler:
>> John Gilmore announced:
>>> After discussions with Jean Snow, the list owner, I have concluded
>>> that my views and, even more, controversial style are incompatible
>>> with her and others' notions of what is proper here.
>>> I am unwilling to conform to these proprieties, and this is therefore
>>> my last post here.
>>
>> Me too "Sorry to see you go.  I always read your posts."(Andrew Joice)
>>
>> I feel bad my screwed-up last post might have been one of those last
>> straws.
>> That post was too long-worded. After deleting the clumsy part I should
>> have adequately expanded what was left or scrapped it altogether. In
>> any case, English is my 4th languge and I belong to those still
>> working at the trailing edge with no 64bit opportunities in sight.
>>
>> I always found your posts worth reading, although at times only with
>> Google Translator assistance. If quitting isn't your style, hopefully
>> a new *Voice from Ashland* will emerge from this. The final decision
>> of course is yours !
>>
>> Andreas F. Geissbuehler
>>
>
>
>--
>Bernd Oppolzer
>---
>*Oppolzer-Informatik
>* Dipl. Inf. Bernd Oppolzer
>Bärenhofstraße 23
>70771 Leinfelden-Echterdingen
>---
>Tel.: +49 711 2272522
>priv.: +49 711 7949590
>eMail: bernd.oppol...@t-online.de 
>---
>Für Umsatzsteuerzwecke:
>SteuerNr.: 97 076 / 29921
>USt-ID-Nr.: DE 147 700 393
>---
>Jubiläumsjahr 2013:
>30 Jahre Oppolzer-Informatik

Re: Subject: New BAL

[Michael Stack]

The "blue card" itself can be seen at
http://archive.michigan-terminal-system.org/documentation/documents/IBM360-67RefCard.pdf

Mike

At 01:15 PM 4/10/2013 -0500, you wrote:
>This green card documents BAS as "Branch and Store" with footnote (e) Model
>67.
>
>http://archive.computerhistory.org/resources/access/text/2010/05/102678081-05-01-acc.pdf
>
>Regards,
>John K
>
>IBM Mainframe Assembler List  wrote on
>04/10/2013 12:01:44 PM:
>
>> From: Scott Ford 
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Date: 04/10/2013 12:14 PM
>> Subject: Re: Subject: New BAL
>> Sent by: IBM Mainframe Assembler List 
>>
>> John,
>>
>> Now you say it seem to remember it on a 360/20 . I learned BAL at
>> that time on a 360/20
>>
>> Scott J Ford
>> Software Engineer
>> http://www.identityforge.com/
>>
>>
>>
>> 
>>  From: John Ehrman 
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Sent: Wednesday, April 10, 2013 12:53 PM
>> Subject: Re: Subject: New BAL
>>
>> John McKown noted...
>> >IIRC, some models of the S/360 had a BAS instruction. But I don't have
>> >an old S/360 POPS to make sure exactly what it did.
>>
>> My old System/360 Green Card has no BAS, but I believe it was available
>on
>> Models 20 and 67.  I don't think it would have been in the 360 PoP.
>> John Ehrman

Re: Subject: New BAL

[Michael Stack]

The 360/67 had a Branch and Store (BAS, BASR) to deal with 32-bit virtual 
addresses.

Mike

At 07:25 AM 4/10/2013 -0500, you wrote:
>IIRC, some models of the S/360 had a BAS instruction. But I don't have
>an old S/360 POPS to make sure exactly what it did.
>
>On Wed, Apr 10, 2013 at 6:52 AM, Peter Relson  wrote:
>>>What's the new Instruction that replaces the old BAL  R14,s ?
>>
>> By new do you mean "30 years old"? If so, the BAS answer seems correct.
>> If you mean "only 15 or so years old", perhaps BRAS is the answer you seek
>> (I did not look up just when the relative-immediate facility was
>> introduced).
>>
>> Peter Relson
>> z/OS Core Technology Design
>
>
>
>--
>This is a test of the Emergency Broadcast System. If this had been an
>actual emergency, do you really think we'd stick around to tell you?
>
>Maranatha! <><
>John McKown

Re: Curosity Question

[Michael Stack]

At 11:30 AM 11/2/2012 +1100, you wrote:
>From: John Gilmore
>Sent: Friday, 2 November 2012 8:25 AM
>
>>Long division is not hashing.
>
>Even long division can be hashing.

Just so. See Knuth, TAoCP, Ch 6.4 .

Mike


>> Dividing and taking the remainder to
>>achieve a more-fewer mapping is---by definition---division-method
>>hashing; and it of course makes use of just one divide operation.

Re: SV: DS 0H

[Michael Stack]

At 05:46 AM 6/13/2012 +0200, Thomas Berg wrote:
>> -Ursprungligt meddelande-
>> Från: IBM Mainframe Assembler List [mailto:ASSEMBLER-
>> l...@listserv.uga.edu] För John Ehrman
>> Skickat: den 13 juni 2012 01:44
>> Till: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Ämne: Re: DS 0H
>>
>> Paul Gilmartin asked:
>> >Does DC not require a nominal value?  I know it used to.
>>
>> No nominal value needed if the duplication factor is zero.
>>
>> John Ehrman
>
>But how does the assembler then know which value it should omit ?
>
>
>
>Regards,
>Thomas Berg

Ha!  "I'm sorry, we're all out of nuts. Would you like that sundae without a 
cherry instead?" (VERY old joke ...)

Mike

Re: code comments

[Michael Stack]

At 03:36 PM 2/10/2012 +, you wrote:
>...
>
>I was taught at an early age to read the code rather than the comments,
>especially when one disagrees with the other.

And I learned at an early age to look at the object code. This rule was 
hammered home when we purchased commercial software which contained such 
oddities as

R3   EQU   5

Michael Stack

Re: How do you do a binary search on a linked list?

[Michael Stack]

Knuth algorithm 6.2.3A (Balanced Tree Search and Insertion) (AVL) is not much 
more work. A couple instructions for a single rotate, a few more when double 
rotate is needed. Students coded it pretty quickly.

Michael Stack

At 03:39 PM 1/19/2012 -0700, you wrote:
>On 1/18/2012 1:20 PM, Gerhard Postpischil wrote:
>>On 1/18/2012 2:45 PM, Michael Stack wrote:
>>>While binary search trees have been mentioned (by John
>>>Gilmore, IIRC), I keep wondering why so many other solutions
>>>are being suggested. For any repetitive search of a linked
>>>list, converting to a BST seems an almost obvious solution.
>>>See Knuth's Algorithm 6.2.2T (Tree Search and Insertion), for
>>>example. Or am I missing something?
>There are a set of POSIX interfaces in /usr/include/search.h
>
>>I suspect, but have no confirmation, that this algorithm is
>>neglected due to Knuth's omission (homework?) of any way to read
>>the tree sequentially, something likely to be required in a
>>commercial environment?
>Perhaps because traversal by recursive descent was deemed trivial?
>
>Alas, none of several implementations of these functions I've tested
>balance the trees.
>
>-- gil

Re: How do you do a binary search on a linked list?

[Michael Stack]

Surely. And if a sequence set is necessary then a more complex structure, 
perhaps a B*-tree, is required. I was simply responding to the requirement to 
search a linked list.

Michael Stack

At 03:20 PM 1/18/2012 -0500, you wrote:
>On 1/18/2012 2:45 PM, Michael Stack wrote:
>>While binary search trees have been mentioned (by John
>>Gilmore, IIRC), I keep wondering why so many other solutions
>>are being suggested. For any repetitive search of a linked
>>list, converting to a BST seems an almost obvious solution.
>>See Knuth's Algorithm 6.2.2T (Tree Search and Insertion), for
>>example. Or am I missing something?
>
>I suspect, but have no confirmation, that this algorithm is
>neglected due to Knuth's omission (homework?) of any way to read
>the tree sequentially, something likely to be required in a
>commercial environment?
>
>Gerhard Postpischil
>Bradford, VT

Re: How do you do a binary search on a linked list?

[Michael Stack]

While binary search trees have been mentioned (by John Gilmore, IIRC), I keep 
wondering why so many other solutions are being suggested. For any repetitive 
search of a linked list, converting to a BST seems an almost obvious solution. 
See Knuth's Algorithm 6.2.2T (Tree Search and Insertion), for example. Or am I 
missing something?

Michael Stack

At 01:47 PM 1/18/2012 -0500, Victor Gil wrote:
>How about this - run through the linked list and collect ALL pointers into
>an array[1:M].
>
>Then do binary search on the array?
>
>HTH,
>-Victor-
>
>On Wed, 18 Jan 2012 10:42:11 +0100, Rob van der Heij 
>wrote:
>
>>On Tue, Jan 17, 2012 at 10:23 PM, Robert A. Rosenberg 
>wrote:
>>
>>> IOW: Run the chain to N/2 and see if we are the High or Low. Then run
>>> forward or backward N/4 pointers (ending up at N/4 or N*3/4 [ie: 1/4
>>> or 3/4 into the chain]). Each time you half the distance between the
>>> current location and half way forward/backward to the prior location
>>> until you get a hit or have bracketed the location to insert a new
>>> record.
>>
>>Running backward requires a double-linked list. Without that, you have
>>to start at the front again when the key comparison shows you're past
>>the point. Keeping bread crumbs could save you one trip, but would
>>make the pointer chase more costly unless hardware does it.
>>
>>Rob

Re: prize for a good replacement for "baseless"

[Michael Stack]

At 07:55 AM 12/19/2010 +1100, you wrote:
>On 19/12/2010 05:32 AM, john gilmore wrote:
>>In  the future "baseless", always an ugly term embodying a dubious pun, will 
>>need explanation.  It will be as helpful as a description of a modern 
>>automobile as "crankless".
>Seldom does one find John in error, and this one may be a language
>difference between Australian and USA usage, but I think most cars still
>have cranks  but not crank handles.
>
>Ken

Staying on off-topic for a moment; it is common usage in the US to refer to 
"cranking" the engine when trying to start it (even without a crank handle).

Mike


Michael Stack
http://www.kcats.org

Re: Instruction Set Architecture

[Michael Stack]

At 08:35 AM 9/8/2010 -0600, you wrote:
>On Sep 8, 2010, at 05:39, robin wrote:
>
>> From: "Tony Harminc"
>> Sent: Wednesday, 8 September 2010 9:20 AM
>>
>>> It's also how "classic" (base & displacement) addressing arithmetic,
>>> which we all know deals only with unsigned values, can subtract.
>>
>> Classic base-displacement atithmetic is always addition,
>> never subtraction.
>
>Ahem.
>
> LHR1,=H'-4096'
> USING -4096,R1
> LAR2,*
> LAR3,-4(,R2)
>
>What does R3 now address?
>
>This caused a great deal of debate on this list several years
>ago.  Very few contributors got it right.
>
>-- gil

This - http://www.kcats.org/csci/464/ho/usingtechnique.shtml - is taken from 
John Ehrman's note of long ago.

Mike

Re: number of new instructions

[Michael Stack]

At 12:15 PM 8/31/2010 -0500, McKown, John wrote:
>...
>
>I think the OP was trying to show how the architecture has advanced from the 
>original S/360 days. One measure is "number of unique opcodes available".
...

Another measure might be the thickness of a printed copy of PoO.  My S/360 
edition is about 3/8" - 1/2" .  Does anyone have an actual printed copy of the 
current PoO?

A page count from Acrobat would work, too. According to Acrobat:

A22-6821-00 (no date - 1964?) has 168 pages.

SA22-7832-07 (Feb 2009) has 1344 pages, exactly(!) eight times the original.

At least this includes a (primitive) measure of the additional complexity, not 
just the instruction count.

Mike (who obviously has too much time on his hands ...)


Michael Stack
http://www.kcats.org

"Cooperation, not coercion"