Re: Change in GETMAIN behavior

[glen herrmannsfeldt]

> From: "Tony Harminc" 
 
> On 19 November 2015 at 10:14, Gary Weinhold  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

[glen herrmannsfeldt]

In article 

replacement CRTs for 3278s

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

(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

[glen herrmannsfeldt]

(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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

 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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

(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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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)

[glen herrmannsfeldt]

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

Re: IBM C compiler substituting for macros inside literals?

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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?

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

(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

[glen herrmannsfeldt]

(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