subject:"hexadecimal\?"

In
cae1xxdf_d59y7eufat1xw5b5omgtwrxhvxojwn9qeefgmzb...@mail.gmail.com,
on 12/08/2013
   at 01:10 PM, John Gilmore jwgli...@gmail.com said:

and I think we all sympathize with the point he is making.  There 
is, however, some real hexadecimal data around, beginning with its 
use in IBM 7090 channel programming.

Nonsense; I/O channels on the 7090 were binary. The fact that the 7909
was an 8-bit channel rather than a 6-bit channel doesn't change that.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

In f9213c4c-fe34-4583-b15a-20ec14a55...@yahoo.com, on 12/08/2013
   at 01:52 PM, Scott Ford scott_j_f...@yahoo.com said:

Huh .maybe you should back to computer basics ...at machine level
everything is binary

Silly wabbit, trits are for kids.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

In
of8230a144.9ea02174-on88257c3c.006cea00-88257c3c.006d8...@sce.com,
on 12/09/2013
   at 11:56 AM, Skip Robinson jo.skip.robin...@sce.com said:

Not sure what's meant by having to chain CCWs.

Read PoOps.

I just finished updating an old RYO program that writes 80 byte 
records to any device specified  because I needed to test 32K 
blocks on tape. I merely added a DCBE

Look at the CCW chains that it builds.

No attempt at chaining,

Are you a betting man?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

In p06240401ceca853cbacd@[192.168.2.101], on 12/08/2013
   at 03:27 PM, Robert A. Rosenberg hal9...@panix.com said:

Data in the computer is stored in 8-bit long bytes.

Data in a computer are stored in units dictated by the architecture.
For the S/360 it's 8-bit[1] bytes. I've seen word sizes of 12, 18, 24,
30, 36, 60 and 64 bits, words size of 10 decimal digits[2] and
character size of 6 bits, and that leaves out the really old stuff.

Silly wabbit, trits are for kids.

[1] In CDC-land the default bytes size was 12.

[2] With either a 2-state sign or a 3-state sign.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

In 9820584016396110.wa.paulgboulderaim@listserv.ua.edu, on
12/08/2013
   at 08:25 PM, Paul Gilmartin paulgboul...@aim.com said:

(The last is the maximum supported by channel programs, or was.)

2^16 is a limitation on a single CCW; it is not a limitation on a CCW
chain, and data chaining goes back to Day One. OTOH, various
controllers had limits much smaller than 2^16.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

In 20131210023525.GC6157@dlc-dt, on 12/09/2013
   at 09:35 PM, David L. Craig dlc@gmail.com said:

Of course, real MVS programmers use STARTIO

Real MVS systems programmers understand the principle of least
privilege and don't write AC(1) code unless it confers an advantage of
some sort. In particular, the don't use STARTIO if EXCP or *SAM will
do the j0ob just as well.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-10 Thread John Eells


Skip Robinson wrote:

Not sure what's meant by having to chain CCWs. I just finished updating an
old RYO program that writes 80 byte records to any device specified
because I needed to test 32K blocks on tape. I merely added a DCBE with
BLKSIZE=0 and pointed to it in the existing DCB. No other changes. Created
a tape file with BLKSIZE=261760 (256K) (as reported by RMM) by specifying
that block size in JCL. No attempt at chaining, which I would not know how
to do anyway.

snip

There are two CCW bits, Chain Command (CC) and Chain Data (CD), that are 
used when chaining CCWs to construct a channel program.  If I recall 
correctly, CC causes the next CCW's command to run and CD causes the 
data address part of the next CCW to be used to continue the operation 
started in a preceding CCW.  No new SSCH is needed for the channel to 
process the chained CCWs.  An entire channel program can run to 
completion with single start.


There are a variety of reasons to chain CCWs, among them performance (no 
redispatch is required to issue the next CCW), particularly for disk. 
Simplicity probably isn't one of them; thank goodness for access methods!


You can also used Program Controlled Interrupts (PCI) to dynamically 
append to a running channel program.  Program Fetch does this for load 
modules, which have text records that vary in length.  If the system has 
enough cycles to spare, you can get an entire load module with a single 
channel program this way, as the lengths are retrieved and used to build 
CCWs on the fly.  If the system is too busy, the channel program ends 
and a new one is built to pick up where it left off until the entire 
module has been fetched.


I have not yet bothered to learn how any of this is done in transfer 
mode (with zHPF), which doesn't actually use CCWs...


--
John Eells
IBM Poughkeepsie

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-10 Thread Scott Ford

John,

I recall the same my knowledge is old..over 20 yrs working on VSE

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 10, 2013, at 10:59 AM, John Eells ee...@us.ibm.com wrote:
 
 Skip Robinson wrote:
 Not sure what's meant by having to chain CCWs. I just finished updating an
 old RYO program that writes 80 byte records to any device specified
 because I needed to test 32K blocks on tape. I merely added a DCBE with
 BLKSIZE=0 and pointed to it in the existing DCB. No other changes. Created
 a tape file with BLKSIZE=261760 (256K) (as reported by RMM) by specifying
 that block size in JCL. No attempt at chaining, which I would not know how
 to do anyway.
 snip
 
 There are two CCW bits, Chain Command (CC) and Chain Data (CD), that are used 
 when chaining CCWs to construct a channel program.  If I recall correctly, CC 
 causes the next CCW's command to run and CD causes the data address part of 
 the next CCW to be used to continue the operation started in a preceding CCW. 
  No new SSCH is needed for the channel to process the chained CCWs.  An 
 entire channel program can run to completion with single start.
 
 There are a variety of reasons to chain CCWs, among them performance (no 
 redispatch is required to issue the next CCW), particularly for disk. 
 Simplicity probably isn't one of them; thank goodness for access methods!
 
 You can also used Program Controlled Interrupts (PCI) to dynamically append 
 to a running channel program.  Program Fetch does this for load modules, 
 which have text records that vary in length.  If the system has enough cycles 
 to spare, you can get an entire load module with a single channel program 
 this way, as the lengths are retrieved and used to build CCWs on the fly.  If 
 the system is too busy, the channel program ends and a new one is built to 
 pick up where it left off until the entire module has been fetched.
 
 I have not yet bothered to learn how any of this is done in transfer mode 
 (with zHPF), which doesn't actually use CCWs...
 
 --
 John Eells
 IBM Poughkeepsie
 
 --
 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: hexadecimal?

2013-12-10 Thread DASDBILL2

I Totally agree with using PCI to implement this insane channel program, which, 
if it could honk through 2,000 tracks per second and never end prematurely, 
would take about 23 days to complete.  And 2,000 tracks per second is 
achievable now, so by the time a fully populated EAV is available the 
sustainable data transfer rate might have improved to where it would take less 
than one day to complete. 

Bill Fairchild 

- Original Message -

From: Tony Harminc t...@harminc.net 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 9, 2013 7:21:53 PM 
Subject: Re: hexadecimal? 

On 9 December 2013 18:04, DASDBILL2 dasdbi...@comcast.net wrote: 
 My phrase billions of CCWs was assuming you already knew how to read a full 
 track with only one CCW. A fully 
 populated EAV can have 16 to the 7th power cylinders and each cylinder can 
 have 15 tracks.  One Read Track CCW 
 (and not Read Multiple CKD, which is too primitive) per track would require 4 
 026 531 840 CCWs, which is four billion, 
 which is billions.  And each CCW would need 56K bytes of real, fixed 
 storage for the life of this I/O request.  That's 
 228 terabytes of real storage, which is the main reason why I called this 
 channel program theoretical. 

In the real world, PCI would be used to modify the channel program on 
the fly. It would presumably be copying the data to another device 
(tape or disk), and as long as that output device could keep up, 
there's no reason for this to be a theoretical-only scheme. 

Much the same thing, on a smaller and slower scale (though perhaps not 
much smaller relative to the hardware of the day) was done by APL\360 
with its terminal I/O. The terminal read channel program was unending, 
with new buffers being chained in based on PCI interrupts. 

Tony H. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-10 Thread DASDBILL2

After learning of the existence of XDAP in one of Dr. Rannie's SHARE 
presentations, I tried it out  when I got home from SHARE.  I found that XDAP 
is much, much easier to use than all the various pieces which must be 
interconnected correctly in order to use EXCP.  XDAP is a macro which expands 
into code that builds a channel program and an IOB, then does an EXCP followed 
immediately by a WAIT.  If you don't need to overlap any other processing in 
between the EXCP and the WAIT. then you can use XDAP, but you will still need 
an OPENed DCB and a DD statement.  Its main drawback, in my opinion, is that 
only a small subset of all possible CCW commands are supported.  But one can 
easily modify the macro's expansion and add code to build a much more 
sophisticated CCW chain.  It's not quick and dirty, but it is quick and simple. 

Bill Fairchild 

- Original Message -

From: David L. Craig dlc@gmail.com 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 9, 2013 8:35:25 PM 
Subject: Re: hexadecimal? 

On 13Dec09:1528-0500, Gerhard Postpischil wrote: 

 On 12/9/2013 2:56 PM, Skip Robinson wrote: 
 
 2) That's a shame. Every programmer can benefit from familiarity 
 with the hardware - write a test program using EXCP to read a 
 multi-volume tape, or use XDAP to read a multi-volume DASD data set 
 with unknown block sizes. 
I remember Dr. Rannie talking about teaching Intro To Channel 
Programming using XDAP, not EXCP, so the students wouldn't have 
to worry about IOBs.  He was challenged to come up with any 
other reason for using XDAP over EXCP. 

Of course, real MVS programmers use STARTIO (unless they cannot 
get their code into an APF library, of course). ;-) 
-- 
not cent from sell 
May the LORD God bless you exceedingly abundantly! 

Dave_Craig__ 
So the universe is not quite as you thought it was. 
 You'd better rearrange your beliefs, then. 
 Because you certainly can't rearrange the universe. 
__--from_Nightfall_by_Asimov/Silverberg_ 

-- 
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: hexadecimal?

2013-12-10 Thread Warren Brown

In the 70s 'TCAM'  it used PCI to function the entire time TCAM was running.  
There was only one channel program that handled

all requests.  If TCAM ran out of work, the channel program would TIC to 
location 2 which cause a channel program check.  TCAM STAE routine would 
recover.



 From: DASDBILL2 dasdbi...@comcast.net
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 10, 2013 11:24 AM
Subject: Re: hexadecimal?
 

I Totally agree with using PCI to implement this insane channel program, which, 
if it could honk through 2,000 tracks per second and never end prematurely, 
would take about 23 days to complete.  And 2,000 tracks per second is 
achievable now, so by the time a fully populated EAV is available the 
sustainable data transfer rate might have improved to where it would take less 
than one day to complete. 

Bill Fairchild 

- Original Message -

From: Tony Harminc t...@harminc.net 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 9, 2013 7:21:53 PM 
Subject: Re: hexadecimal? 

On 9 December 2013 18:04, DASDBILL2 dasdbi...@comcast.net wrote: 
 My phrase billions of CCWs was assuming you already knew how to read a full 
 track with only one CCW. A fully 
 populated EAV can have 16 to the 7th power cylinders and each cylinder can 
 have 15 tracks.  One Read Track CCW 
 (and not Read Multiple CKD, which is too primitive) per track would require 4 
 026 531 840 CCWs, which is four billion, 
 which is billions.  And each CCW would need 56K bytes of real, fixed 
 storage for the life of this I/O request.  That's 
 228 terabytes of real storage, which is the main reason why I called this 
 channel program theoretical. 

In the real world, PCI would be used to modify the channel program on 
the fly. It would presumably be copying the data to another device 
(tape or disk), and as long as that output device could keep up, 
there's no reason for this to be a theoretical-only scheme. 

Much the same thing, on a smaller and slower scale (though perhaps not 
much smaller relative to the hardware of the day) was done by APL\360 
with its terminal I/O. The terminal read channel program was unending, 
with new buffers being chained in based on PCI interrupts. 

Tony H. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-10 Thread Scott Ford

Bill,

I haven't been fortunate enough to go to Share..I wish

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 10, 2013, at 11:32 AM, DASDBILL2 dasdbi...@comcast.net wrote:
 
 After learning of the existence of XDAP in one of Dr. Rannie's SHARE 
 presentations, I tried it out  when I got home from SHARE.  I found that XDAP 
 is much, much easier to use than all the various pieces which must be 
 interconnected correctly in order to use EXCP.  XDAP is a macro which expands 
 into code that builds a channel program and an IOB, then does an EXCP 
 followed immediately by a WAIT.  If you don't need to overlap any other 
 processing in between the EXCP and the WAIT. then you can use XDAP, but you 
 will still need an OPENed DCB and a DD statement.  Its main drawback, in my 
 opinion, is that only a small subset of all possible CCW commands are 
 supported.  But one can easily modify the macro's expansion and add code to 
 build a much more sophisticated CCW chain.  It's not quick and dirty, but it 
 is quick and simple. 
 
 Bill Fairchild 
 
 - Original Message -
 
 From: David L. Craig dlc@gmail.com 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Monday, December 9, 2013 8:35:25 PM 
 Subject: Re: hexadecimal? 
 
 On 13Dec09:1528-0500, Gerhard Postpischil wrote: 
 
 On 12/9/2013 2:56 PM, Skip Robinson wrote: 
 
 2) That's a shame. Every programmer can benefit from familiarity 
 with the hardware - write a test program using EXCP to read a 
 multi-volume tape, or use XDAP to read a multi-volume DASD data set 
 with unknown block sizes.
 I remember Dr. Rannie talking about teaching Intro To Channel 
 Programming using XDAP, not EXCP, so the students wouldn't have 
 to worry about IOBs.  He was challenged to come up with any 
 other reason for using XDAP over EXCP. 
 
 Of course, real MVS programmers use STARTIO (unless they cannot 
 get their code into an APF library, of course). ;-) 
 -- 
 not cent from sell 
 May the LORD God bless you exceedingly abundantly! 
 
 Dave_Craig__ 
 So the universe is not quite as you thought it was. 
  You'd better rearrange your beliefs, then. 
  Because you certainly can't rearrange the universe. 
 __--from_Nightfall_by_Asimov/Silverberg_ 
 
 -- 
 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: hexadecimal?

2013-12-10 Thread Rouse, Willie

Warren how's your new job

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Warren Brown
Sent: Tuesday, December 10, 2013 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: hexadecimal?

In the 70s 'TCAM'  it used PCI to function the entire time TCAM was running.  
There was only one channel program that handled

all requests.  If TCAM ran out of work, the channel program would TIC to 
location 2 which cause a channel program check.  TCAM STAE routine would 
recover.

 From: DASDBILL2 dasdbi...@comcast.net
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 10, 2013 11:24 AM
Subject: Re: hexadecimal?

I Totally agree with using PCI to implement this insane channel program, which, 
if it could honk through 2,000 tracks per second and never end prematurely, 
would take about 23 days to complete.  And 2,000 tracks per second is 
achievable now, so by the time a fully populated EAV is available the 
sustainable data transfer rate might have improved to where it would take less 
than one day to complete. 

Bill Fairchild 

- Original Message -

From: Tony Harminc t...@harminc.net 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 9, 2013 7:21:53 PM 
Subject: Re: hexadecimal? 

On 9 December 2013 18:04, DASDBILL2 dasdbi...@comcast.net wrote: 
 My phrase billions of CCWs was assuming you already knew how to read a full 
 track with only one CCW. A fully 
 populated EAV can have 16 to the 7th power cylinders and each cylinder can 
 have 15 tracks.  One Read Track CCW 
 (and not Read Multiple CKD, which is too primitive) per track would require 4 
 026 531 840 CCWs, which is four billion, 
 which is billions.  And each CCW would need 56K bytes of real, fixed 
 storage for the life of this I/O request.  That's 
 228 terabytes of real storage, which is the main reason why I called this 
 channel program theoretical. 

In the real world, PCI would be used to modify the channel program on 
the fly. It would presumably be copying the data to another device 
(tape or disk), and as long as that output device could keep up, 
there's no reason for this to be a theoretical-only scheme. 

Much the same thing, on a smaller and slower scale (though perhaps not 
much smaller relative to the hardware of the day) was done by APL\360 
with its terminal I/O. The terminal read channel program was unending, 
with new buffers being chained in based on PCI interrupts. 

Tony H. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: hexadecimal?

2013-12-10 Thread DASDBILL2

Old SHARE proceedings are online. 

Bill Fairchld 

- Original Message -

From: Scott Ford scott_j_f...@yahoo.com 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 10, 2013 10:41:30 AM 
Subject: Re: hexadecimal? 

Bill, 

I haven't been fortunate enough to go to Share..I wish 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-10 Thread Scott Ford

Bill,

Ty, I will look much appreciated

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 10, 2013, at 11:45 AM, DASDBILL2 dasdbi...@comcast.net wrote:
 
 Old SHARE proceedings are online. 
 
 Bill Fairchld 
 
 - Original Message -
 
 From: Scott Ford scott_j_f...@yahoo.com 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Tuesday, December 10, 2013 10:41:30 AM 
 Subject: Re: hexadecimal? 
 
 Bill, 
 
 I haven't been fortunate enough to go to Share..I wish 
 
 --
 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: hexadecimal?

Everybody please quiesce the  road rage. 

Circuits work in voltages. 

Bill Fairchld 

Franklin, TN 

- Original Message -

From: Scott Ford scott_j_f...@yahoo.com 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Sunday, December 8, 2013 1:28:10 PM 
Subject: Re: hexadecimal? 

What do circuits work in  ... 

Scott ford 
www.identityforge.com 
from my IPAD 

'Infinite wisdom through infinite means' 


 On Dec 8, 2013, at 2:07 PM, David L. Craig dlc@gmail.com wrote: 
 
 On 13Dec08:1352-0500, Scott Ford wrote: 
 
 Huh .maybe you should back to computer basics 
 ...at machine level everything is binary 
 
 Scott ford 
 www.identityforge.com 
 from my IPAD 
 
 You, sir, are the one who needs to go back--specifically 
 to zPOPs page 9-3: 
 
 : Hexadecimal-Floating-Point (HFP) 
 : 
 : Hexadecimal-floating-point (HFP) operands have for- 
 : mats which provide for exponents that specify pow- 
 : ers of the radix 16 and significands that are 
 : hexadecimal numbers. The exponent range is the 
 : same for the short, long, and extended formats. The 
 : results of most operations on HFP data are truncated 
 : to fit into the target format, but there are instructions 
 : available to round the result when converting to a 
 : narrower format. For HFP operands, the implicit unit 
 : digit of the significand is always zero. Since the value 
 : of the significand and fraction are the same, HFP 
 : operations are described in terms of the fraction, and 
 : the term significand is not used. 
 : 
 : Either normalized or unnormalized numbers may be 
 : used as operands for any HFP or DFP operation, 
 : where, for HFP, a normalized number is one having a 
 : nonzero leftmost fraction digit, or, for DFP, a normal- 
 : ized number is one having a nonzero leftmost signifi- 
 : cand digit. Most HFP instructions generate 
 : normalized results for greatest precision. HFP add 
 : and subtract instructions that generate unnormalized 
 : results are also available. 
 -- 
 not cent from sell 
 May the LORD God bless you exceedingly abundantly! 
 
 Dave_Craig__ 
 So the universe is not quite as you thought it was. 
 You'd better rearrange your beliefs, then. 
 Because you certainly can't rearrange the universe. 
 __--from_Nightfall_by_Asimov/Silverberg_ 
 
 -- 
 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: hexadecimal?

Channel programs have always been able to transfer anywhere from zero to 65,535 
bytes per CCW.  Most access methods do not support any CCW byte count greater 
than approximately 32K. 
To render my first sentence more up-to-date, I should say channel programs 
running in command mode have always been able... etc. (since transfer mode 
channel programs have no CCWs in them). 
  
Bill Fairchild 
Franklin, TN 

- Original Message -

From: Paul Gilmartin paulgboul...@aim.com 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Sunday, December 8, 2013 8:25:50 PM 
Subject: Re: hexadecimal? 

On Sun, 8 Dec 2013 20:01:20 -0600, Joel C. Ewing wrote: 
 
If the real requirement is that the parameter address must point to a 
location containing what the PoOp describes as a half-word binary value, 
then the manual should state precisely that. 
 
Thanks for bringing this thread back to my original concern when I 
started it (I never imagined! ...), however interesting the digressions 
to HFP and ternary logic may be, and for stating that concern more 
clearly than I did. 

There should also be mention of the allowable range of values: 
0n=32760?  0n=BLKSIZE?  0ntrack-size?  0n=65535? 
(The last is the maximum supported by channel programs, or was.) 
Are unsigned halfwords supported?  This became an issue about the 
advent of the 3380. 

Clearly the present text of the manual engenders confusion and 
dissent. 

-- 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: hexadecimal?

2013-12-09 Thread Scott Ford

Bill,

Absolutely, father was a CE

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 9, 2013, at 10:13 AM, DASDBILL2 dasdbi...@comcast.net wrote:
 
 Everybody please quiesce the  road rage. 
 
 Circuits work in voltages. 
 
 Bill Fairchld 
 
 Franklin, TN 
 
 - Original Message -
 
 From: Scott Ford scott_j_f...@yahoo.com 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Sunday, December 8, 2013 1:28:10 PM 
 Subject: Re: hexadecimal? 
 
 What do circuits work in  ... 
 
 Scott ford 
 www.identityforge.com 
 from my IPAD 
 
 'Infinite wisdom through infinite means' 
 
 
 On Dec 8, 2013, at 2:07 PM, David L. Craig dlc@gmail.com wrote: 
 
 On 13Dec08:1352-0500, Scott Ford wrote: 
 
 Huh .maybe you should back to computer basics 
 ...at machine level everything is binary 
 
 Scott ford 
 www.identityforge.com 
 from my IPAD
 
 You, sir, are the one who needs to go back--specifically 
 to zPOPs page 9-3: 
 
 : Hexadecimal-Floating-Point (HFP) 
 : 
 : Hexadecimal-floating-point (HFP) operands have for- 
 : mats which provide for exponents that specify pow- 
 : ers of the radix 16 and significands that are 
 : hexadecimal numbers. The exponent range is the 
 : same for the short, long, and extended formats. The 
 : results of most operations on HFP data are truncated 
 : to fit into the target format, but there are instructions 
 : available to round the result when converting to a 
 : narrower format. For HFP operands, the implicit unit 
 : digit of the significand is always zero. Since the value 
 : of the significand and fraction are the same, HFP 
 : operations are described in terms of the fraction, and 
 : the term significand is not used. 
 : 
 : Either normalized or unnormalized numbers may be 
 : used as operands for any HFP or DFP operation, 
 : where, for HFP, a normalized number is one having a 
 : nonzero leftmost fraction digit, or, for DFP, a normal- 
 : ized number is one having a nonzero leftmost signifi- 
 : cand digit. Most HFP instructions generate 
 : normalized results for greatest precision. HFP add 
 : and subtract instructions that generate unnormalized 
 : results are also available. 
 -- 
 not cent from sell 
 May the LORD God bless you exceedingly abundantly! 
 
 Dave_Craig__ 
 So the universe is not quite as you thought it was. 
 You'd better rearrange your beliefs, then. 
 Because you certainly can't rearrange the universe. 
 __--from_Nightfall_by_Asimov/Silverberg_ 
 
 -- 
 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: hexadecimal?

2013-12-09 Thread Scott Ford

All,

Let's get back on Gil's questioned pls..

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 9, 2013, at 10:13 AM, DASDBILL2 dasdbi...@comcast.net wrote:
 
 Everybody please quiesce the  road rage. 
 
 Circuits work in voltages. 
 
 Bill Fairchld 
 
 Franklin, TN 
 
 - Original Message -
 
 From: Scott Ford scott_j_f...@yahoo.com 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Sunday, December 8, 2013 1:28:10 PM 
 Subject: Re: hexadecimal? 
 
 What do circuits work in  ... 
 
 Scott ford 
 www.identityforge.com 
 from my IPAD 
 
 'Infinite wisdom through infinite means' 
 
 
 On Dec 8, 2013, at 2:07 PM, David L. Craig dlc@gmail.com wrote: 
 
 On 13Dec08:1352-0500, Scott Ford wrote: 
 
 Huh .maybe you should back to computer basics 
 ...at machine level everything is binary 
 
 Scott ford 
 www.identityforge.com 
 from my IPAD
 
 You, sir, are the one who needs to go back--specifically 
 to zPOPs page 9-3: 
 
 : Hexadecimal-Floating-Point (HFP) 
 : 
 : Hexadecimal-floating-point (HFP) operands have for- 
 : mats which provide for exponents that specify pow- 
 : ers of the radix 16 and significands that are 
 : hexadecimal numbers. The exponent range is the 
 : same for the short, long, and extended formats. The 
 : results of most operations on HFP data are truncated 
 : to fit into the target format, but there are instructions 
 : available to round the result when converting to a 
 : narrower format. For HFP operands, the implicit unit 
 : digit of the significand is always zero. Since the value 
 : of the significand and fraction are the same, HFP 
 : operations are described in terms of the fraction, and 
 : the term significand is not used. 
 : 
 : Either normalized or unnormalized numbers may be 
 : used as operands for any HFP or DFP operation, 
 : where, for HFP, a normalized number is one having a 
 : nonzero leftmost fraction digit, or, for DFP, a normal- 
 : ized number is one having a nonzero leftmost signifi- 
 : cand digit. Most HFP instructions generate 
 : normalized results for greatest precision. HFP add 
 : and subtract instructions that generate unnormalized 
 : results are also available. 
 -- 
 not cent from sell 
 May the LORD God bless you exceedingly abundantly! 
 
 Dave_Craig__ 
 So the universe is not quite as you thought it was. 
 You'd better rearrange your beliefs, then. 
 Because you certainly can't rearrange the universe. 
 __--from_Nightfall_by_Asimov/Silverberg_ 
 
 -- 
 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: hexadecimal?

2013-12-09 Thread Scott Ford

Bill,
I thought you could chain ccws

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 9, 2013, at 10:42 AM, DASDBILL2 dasdbi...@comcast.net wrote:
 
 Channel programs have always been able to transfer anywhere from zero to 
 65,535 bytes per CCW.  Most access methods do not support any CCW byte count 
 greater than approximately 32K. 
 To render my first sentence more up-to-date, I should say channel programs 
 running in command mode have always been able... etc. (since transfer mode 
 channel programs have no CCWs in them). 
   
 Bill Fairchild 
 Franklin, TN 
 
 - Original Message -
 
 From: Paul Gilmartin paulgboul...@aim.com 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Sunday, December 8, 2013 8:25:50 PM 
 Subject: Re: hexadecimal? 
 
 On Sun, 8 Dec 2013 20:01:20 -0600, Joel C. Ewing wrote: 
 
 If the real requirement is that the parameter address must point to a 
 location containing what the PoOp describes as a half-word binary value, 
 then the manual should state precisely that. 
 
 Thanks for bringing this thread back to my original concern when I 
 started it (I never imagined! ...), however interesting the digressions 
 to HFP and ternary logic may be, and for stating that concern more 
 clearly than I did. 
 
 There should also be mention of the allowable range of values: 
 0n=32760?  0n=BLKSIZE?  0ntrack-size?  0n=65535? 
 (The last is the maximum supported by channel programs, or was.) 
 Are unsigned halfwords supported?  This became an issue about the 
 advent of the 3380. 
 
 Clearly the present text of the manual engenders confusion and 
 dissent. 
 
 -- 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-09 Thread Anne Lynn Wheeler

gerh...@valley.net (Gerhard Postpischil) writes:
 I think you misread his message, which started with command
 chaining. But I would be interested in which control units and
 controllers allow data chaining beyond 65KiB.

re:
http://www.garlic.com/~lynn/2013o.html#6 hexadecimal

note a lot of original data chaining was for non-contiguous storage
transfers (scatter/gather). cp67 doing emulated i/o had to use it for
shadow ccws involving (non-contiguous) page crossing. channel
architecture proscribes that ccws aren't prefetched (executed serially
one at a time, even datachaining) ... and their could be timing
difficulties with cp67 emulated i/o ... when the native
(non-datachained) i/o ran find.

the issue of page non-contigious i/o was addressed in 370 with IDALs ...
where IDAL channel architecture allowed the the addresses to be
pre-fetched. IDALs was also used later as part of hack adding more than
16mbytes to 3033 ... even tho instructions and CCWs couldn't address
more than 16mbytes.

note that many of the i/o devices are now industry standard with IBM
legacy controllers and devices (like CKD) purely a simulated
artifact. They aren't restricted to record lengths imposed by IBM's
legacy CCW architecture.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-09 Thread Blaicher, Christopher Y.

Tape devices for BLKSIZE greater than 64K-1.  You have to chain a number of 
CCW's together for a BLKSIZE=256K.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803    
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard Postpischil
Sent: Monday, December 09, 2013 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: hexadecimal?

On 12/9/2013 11:53 AM, Scott Ford wrote:
 Bill,
 I thought you could chain ccws

I think you misread his message, which started with command chaining. 
But I would be interested in which control units and controllers allow data 
chaining beyond 65KiB.

Gerhard Postpischil
Bradford, Vermont

--
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: hexadecimal?

2013-12-09 Thread Skip Robinson

Not sure what's meant by having to chain CCWs. I just finished updating an 
old RYO program that writes 80 byte records to any device specified 
because I needed to test 32K blocks on tape. I merely added a DCBE with 
BLKSIZE=0 and pointed to it in the existing DCB. No other changes. Created 
a tape file with BLKSIZE=261760 (256K) (as reported by RMM) by specifying 
that block size in JCL. No attempt at chaining, which I would not know how 
to do anyway. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Blaicher, Christopher Y. cblaic...@syncsort.com
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   12/09/2013 10:31 AM
Subject:Re: hexadecimal?
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Tape devices for BLKSIZE greater than 64K-1.  You have to chain a number 
of CCW's together for a BLKSIZE=256K.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Gerhard Postpischil
Sent: Monday, December 09, 2013 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: hexadecimal?

On 12/9/2013 11:53 AM, Scott Ford wrote:
 Bill,
 I thought you could chain ccws

I think you misread his message, which started with command chaining. 
But I would be interested in which control units and controllers allow 
data chaining beyond 65KiB.

Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-09 Thread Gerhard Postpischil


On 12/9/2013 2:56 PM, Skip Robinson wrote:

Not sure what's meant by having to chain CCWs. I just finished updating an
old RYO program that writes 80 byte records to any device specified
because I needed to test 32K blocks on tape. I merely added a DCBE with
BLKSIZE=0 and pointed to it in the existing DCB. No other changes. Created
a tape file with BLKSIZE=261760 (256K) (as reported by RMM) by specifying
that block size in JCL. No attempt at chaining, which I would not know how
to do anyway.


1) The access method does the chaining for you. If you make the device 
not ready while its reading or writing, and take a dump, you will find 
both the xSAM CCWs and the converted CCW(s) and the IDAL.


2) That's a shame. Every programmer can benefit from familiarity with 
the hardware - write a test program using EXCP to read a multi-volume 
tape, or use XDAP to read a multi-volume DASD data set with unknown 
block sizes.


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

In a command channel program, you can chain any number of CCWs together, each 
of which can possibly transfer up to X'' bytes.  It's theoretically 
possible to have one very long chain that copies an entire EVA DASD to 
somewhere else in only one I/O request; i.e., only one SSCH.  You would need a 
lot of real storage and billions of CCWs, but it's theoretically possible. 
Bill Fairchild 

- Original Message -

From: Scott Ford scott_j_f...@yahoo.com 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 9, 2013 10:53:03 AM 
Subject: Re: hexadecimal? 

Bill, 
I thought you could chain ccws 

Scott ford 
www.identityforge.com 
from my IPAD 

'Infinite wisdom through infinite means' 


 On Dec 9, 2013, at 10:42 AM, DASDBILL2 dasdbi...@comcast.net wrote: 
 
 Channel programs have always been able to transfer anywhere from zero to 
 65,535 bytes per CCW.  Most access methods do not support any CCW byte count 
 greater than approximately 32K. 
 To render my first sentence more up-to-date, I should say channel programs 
 running in command mode have always been able... etc. (since transfer mode 
 channel programs have no CCWs in them). 
   
 Bill Fairchild 
 Franklin, TN 
 
 - Original Message - 
 
 From: Paul Gilmartin paulgboul...@aim.com 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Sunday, December 8, 2013 8:25:50 PM 
 Subject: Re: hexadecimal? 
 
 On Sun, 8 Dec 2013 20:01:20 -0600, Joel C. Ewing wrote: 
 
 If the real requirement is that the parameter address must point to a 
 location containing what the PoOp describes as a half-word binary value, 
 then the manual should state precisely that. 
 
 Thanks for bringing this thread back to my original concern when I 
 started it (I never imagined! ...), however interesting the digressions 
 to HFP and ternary logic may be, and for stating that concern more 
 clearly than I did. 
 
 There should also be mention of the allowable range of values: 
 0n=32760?  0n=BLKSIZE?  0ntrack-size?  0n=65535? 
 (The last is the maximum supported by channel programs, or was.) 
 Are unsigned halfwords supported?  This became an issue about the 
 advent of the 3380. 
 
 Clearly the present text of the manual engenders confusion and 
 dissent. 
 
 -- 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 

-- 
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: hexadecimal?

2013-12-09 Thread John McKown

The only EXCP that I every wrote as at my first job. It read cards from an
actual card reader and would do a select output tray (sorry don't
remember actual terminology) based on whether the card in question passed
initial validation testing. So that the bad cards could be gathered up
and sent back to the department that gave them to us.


On Mon, Dec 9, 2013 at 2:28 PM, Gerhard Postpischil gerh...@valley.netwrote:

 On 12/9/2013 2:56 PM, Skip Robinson wrote:

 Not sure what's meant by having to chain CCWs. I just finished updating an
 old RYO program that writes 80 byte records to any device specified
 because I needed to test 32K blocks on tape. I merely added a DCBE with
 BLKSIZE=0 and pointed to it in the existing DCB. No other changes. Created
 a tape file with BLKSIZE=261760 (256K) (as reported by RMM) by specifying
 that block size in JCL. No attempt at chaining, which I would not know how
 to do anyway.


 1) The access method does the chaining for you. If you make the device not
 ready while its reading or writing, and take a dump, you will find both the
 xSAM CCWs and the converted CCW(s) and the IDAL.

 2) That's a shame. Every programmer can benefit from familiarity with the
 hardware - write a test program using EXCP to read a multi-volume tape, or
 use XDAP to read a multi-volume DASD data set with unknown block sizes.

 Gerhard Postpischil
 Bradford, Vermont

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

Maranatha! 
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

In the late 1970s, I worked at a service bureau where I had to write a tape 
file conversion program to reblock a tape file with 640KB blocks to a much 
smaller physical block size that could be handled by QSAM.  My program read in 
one block with an EXCP and 10 CCWs data chained, each of which read in 64KB 
bytes, all into one buffer of 640KB bytes long.  Then I copied the buffer into 
20 32KB blocks to an output tape using QSAM.  Then I read the next input tape 
block, etc., until the input found the end-of-file marker.  It worked.  But I 
had to run it under MVT running under VM, and VM kept doing funny things with 
the massive real channel program built by MVT's I/O Supervisor that caused 
chaining checks at random places in the chain, so I reran the job until I had 
an execution with no I/O errors. 

The CCW architecture allows 64KB per CCW and any number of CCWs chained 
together.  Control unit limitations are smaller.  Software limitations are 
smaller still.  I don't think anything good would happen on a DASD controller 
now if you fed it a CCW with a byte count longer than one full track (ca. 58K 
bytes).  But the CCW architecture would not be the limiting factor. 

Bill Fairchild 

  

- Original Message -

From: Gerhard Postpischil gerh...@valley.net 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 9, 2013 11:53:52 AM 
Subject: Re: hexadecimal? 

On 12/9/2013 11:53 AM, Scott Ford wrote: 
 Bill, 
 I thought you could chain ccws 

I think you misread his message, which started with command chaining. 
But I would be interested in which control units and controllers allow 
data chaining beyond 65KiB. 

Gerhard Postpischil 
Bradford, Vermont 

-- 
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: hexadecimal?

2013-12-09 Thread Anne Lynn Wheeler

dasdbi...@comcast.net (DASDBILL2) writes:
 In the late 1970s, I worked at a service bureau where I had to write a
 tape file conversion program to reblock a tape file with 640KB blocks
 to a much smaller physical block size that could be handled by QSAM. 
 My program read in one block with an EXCP and 10 CCWs data chained,
 each of which read in 64KB bytes, all into one buffer of 640KB bytes
 long.  Then I copied the buffer into 20 32KB blocks to an output tape
 using QSAM.  Then I read the next input tape block, etc., until the
 input found the end-of-file marker.  It worked.  But I had to run it
 under MVT running under VM, and VM kept doing funny things with the
 massive real channel program built by MVT's I/O Supervisor that
 caused chaining checks at random places in the chain, so I reran the
 job until I had an execution with no I/O errors.

re:
http://www.garlic.com/~lynn/2013o.html#6 hexadecimal?
http://www.garlic.com/~lynn/2013o.html#10 hexadecimal?

aka MVT thinking it ran real memory, EXCP could just tic to the passed
channel program ... cp67vm370 has to make a copy of the virtual machine
channel program that accounts for virtual pages that aren't contiguous
in real storage (with additional data chaining and/or idals)

with move of MVT to virtual memory and OS/VS2 ... EXCP was forced to do
the same as cp67vm370 ... creating a copy of the passed application
channel program that could account of virtual pages that weren't
contiguous in real storage. In fact the original implementation of
adding virtual memory support to MVT for OS/VS2 involved hacking CP67's
routine that built the copied channel programs (CCWTRANS) into the side
of EXCP processing.

The latencies for the additional channel overhead/processing (for the
copied channel program and non-contiguous real addresses introduced with
virtual memory) could result in overruns.

The 370/158 channel processing throughput/overhead tended to be
especially a problem (158 microcode engine was shared between executing
370 emulation and channel emulation) even compared to 370/145.

similar channel latency problems then show up in all the 303x machines
(even with dedicated 370/158 microcode engine for the channel
processing).  as part of the mad rush to get stuff back into the 370
product pipelines (after the failure of future system effort) ... the
303x channel director was created which was a 370/158 microcode engine
w/o the 370 microcode and just the channel emulation. The 3031 was a
370/158 microcode engine with the 370 microcode (and w/o the channel
microcode) and a separate 370/158 microcode engine as a channel
director. The 3032 was 370/168 reconfigured to work with channel
director. The 3033 was 370/168 logic remapped to 20% faster chips.
http://www.garlic.com/~lynn/submain.html#futuresys

i mentioned getting to play disk engineer in bldgs. 1415 and one of the
things that got done was profile typical channel processing latencies of
the different processor models.
http://www.garlic.com/~lynn/subtopic.html#disk

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-09 Thread Blaicher, Christopher Y.

I am guessing that you used a QSAM access method and it does all that for you 
under the covers.  BSAM would also build a data chained CCW string under the 
covers for you, but I think you would have mentioned some of the other things 
you have to do if you were using BSAM.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803    
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Monday, December 09, 2013 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: hexadecimal?

Not sure what's meant by having to chain CCWs. I just finished updating an old 
RYO program that writes 80 byte records to any device specified because I 
needed to test 32K blocks on tape. I merely added a DCBE with
BLKSIZE=0 and pointed to it in the existing DCB. No other changes. Created a 
tape file with BLKSIZE=261760 (256K) (as reported by RMM) by specifying that 
block size in JCL. No attempt at chaining, which I would not know how to do 
anyway. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Blaicher, Christopher Y. cblaic...@syncsort.com
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   12/09/2013 10:31 AM
Subject:Re: hexadecimal?
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Tape devices for BLKSIZE greater than 64K-1.  You have to chain a number 
of CCW's together for a BLKSIZE=256K.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Gerhard Postpischil
Sent: Monday, December 09, 2013 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: hexadecimal?

On 12/9/2013 11:53 AM, Scott Ford wrote:
 Bill,
 I thought you could chain ccws

I think you misread his message, which started with command chaining. 
But I would be interested in which control units and controllers allow 
data chaining beyond 65KiB.

Gerhard Postpischil
Bradford, Vermont

--
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: hexadecimal?

2013-12-09 Thread Harry Wahl




You would need a lot of real storage and billions of CCWs, but it's 
theoretically possible.
You wouldn't need billions of CCWs, you could use the READ MULTIPLE CKD 
command (X'5E') or the READ TRACK command (X'DE') and have one read CCW per 
track along with whatever setup and positioning CCWs are necessary.
These CCW commands are what DUMP/RESTORE programs use.
Of course, if something unexpected occurs, e.g. an unformatted or malformed 
track, your chain would be interrupted, but the chain could then be restarted.
What Bill is suggesting is more than theoretical, it is quite common.
Harry 

 Date: Mon, 9 Dec 2013 20:30:17 +
 From: dasdbi...@comcast.net
 Subject: Re: hexadecimal?
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 In a command channel program, you can chain any number of CCWs together, each 
 of which can possibly transfer up to X'' bytes.  It's theoretically 
 possible to have one very long chain that copies an entire EVA DASD to 
 somewhere else in only one I/O request; i.e., only one SSCH.  You would need 
 a lot of real storage and billions of CCWs, but it's theoretically possible. 
 Bill Fairchild 
 
 - Original Message -
 
 From: Scott Ford scott_j_f...@yahoo.com 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Monday, December 9, 2013 10:53:03 AM 
 Subject: Re: hexadecimal? 
 
 Bill, 
 I thought you could chain ccws 
 
 Scott ford 
 www.identityforge.com 
 from my IPAD 
 
 'Infinite wisdom through infinite means' 
 
 
  On Dec 9, 2013, at 10:42 AM, DASDBILL2 dasdbi...@comcast.net wrote: 
  
  Channel programs have always been able to transfer anywhere from zero to 
  65,535 bytes per CCW.  Most access methods do not support any CCW byte 
  count greater than approximately 32K. 
  To render my first sentence more up-to-date, I should say channel programs 
  running in command mode have always been able... etc. (since transfer mode 
  channel programs have no CCWs in them). 

  Bill Fairchild 
  Franklin, TN 
  
  - Original Message - 
  
  From: Paul Gilmartin paulgboul...@aim.com 
  To: IBM-MAIN@LISTSERV.UA.EDU 
  Sent: Sunday, December 8, 2013 8:25:50 PM 
  Subject: Re: hexadecimal? 
  
  On Sun, 8 Dec 2013 20:01:20 -0600, Joel C. Ewing wrote: 
  
  If the real requirement is that the parameter address must point to a 
  location containing what the PoOp describes as a half-word binary value, 
  then the manual should state precisely that. 
  
  Thanks for bringing this thread back to my original concern when I 
  started it (I never imagined! ...), however interesting the digressions 
  to HFP and ternary logic may be, and for stating that concern more 
  clearly than I did. 
  
  There should also be mention of the allowable range of values: 
  0n=32760?  0n=BLKSIZE?  0ntrack-size?  0n=65535? 
  (The last is the maximum supported by channel programs, or was.) 
  Are unsigned halfwords supported?  This became an issue about the 
  advent of the 3380. 
  
  Clearly the present text of the manual engenders confusion and 
  dissent. 
  
  -- 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 
 
 -- 
 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: hexadecimal?

My phrase billions of CCWs was assuming you already knew how to read a full 
track with only one CCW. A fully populated EAV can have 16 to the 7th power 
cylinders and each cylinder can have 15 tracks.  One Read Track CCW (and not 
Read Multiple CKD, which is too primitive) per track would require 4 026 531 
840 CCWs, which is four billion, which is billions.  And each CCW would need 
56K bytes of real, fixed storage for the life of this I/O request.  That's 228 
terabytes of real storage, which is the main reason why I called this channel 
program theoretical.  The CCW architecture allows for an infinite number of 
CCWs to be chained together.  The channel subsystem honors the  chaining flags 
by adding 8 to the real address of the current CCW to get the  address of the 
next CCW to use to continue the I/O operation, and this process will never stop 
until some real limitation is reached, such as the end of real storage, or the 
job's submitter dies before the one I/O request ends and the operator cancels 
the job, hopefully without the dump option.  :-) 
Bill Fairchild 
Franklin, TN 

- Original Message -

From: Harry Wahl harry_w...@hotmail.com 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 9, 2013 4:41:21 PM 
Subject: Re: hexadecimal? 




You would need a lot of real storage and billions of CCWs, but it's 
theoretically possible. 
You wouldn't need billions of CCWs, you could use the READ MULTIPLE CKD 
command (X'5E') or the READ TRACK command (X'DE') and have one read CCW per 
track along with whatever setup and positioning CCWs are necessary. 
These CCW commands are what DUMP/RESTORE programs use. 
Of course, if something unexpected occurs, e.g. an unformatted or malformed 
track, your chain would be interrupted, but the chain could then be restarted. 
What Bill is suggesting is more than theoretical, it is quite common. 
Harry 

 Date: Mon, 9 Dec 2013 20:30:17 + 
 From: dasdbi...@comcast.net 
 Subject: Re: hexadecimal? 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 
 In a command channel program, you can chain any number of CCWs together, each 
 of which can possibly transfer up to X'' bytes.  It's theoretically 
 possible to have one very long chain that copies an entire EVA DASD to 
 somewhere else in only one I/O request; i.e., only one SSCH.  You would need 
 a lot of real storage and billions of CCWs, but it's theoretically possible. 
 Bill Fairchild 
 
 - Original Message - 
 
 From: Scott Ford scott_j_f...@yahoo.com 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Monday, December 9, 2013 10:53:03 AM 
 Subject: Re: hexadecimal? 
 
 Bill, 
 I thought you could chain ccws 
 
 Scott ford 
 www.identityforge.com 
 from my IPAD 
 
 'Infinite wisdom through infinite means' 
 
 
  On Dec 9, 2013, at 10:42 AM, DASDBILL2 dasdbi...@comcast.net wrote: 
  
  Channel programs have always been able to transfer anywhere from zero to 
  65,535 bytes per CCW.  Most access methods do not support any CCW byte 
  count greater than approximately 32K. 
  To render my first sentence more up-to-date, I should say channel programs 
  running in command mode have always been able... etc. (since transfer mode 
  channel programs have no CCWs in them). 
    
  Bill Fairchild 
  Franklin, TN 
  
  - Original Message - 
  
  From: Paul Gilmartin paulgboul...@aim.com 
  To: IBM-MAIN@LISTSERV.UA.EDU 
  Sent: Sunday, December 8, 2013 8:25:50 PM 
  Subject: Re: hexadecimal? 
  
  On Sun, 8 Dec 2013 20:01:20 -0600, Joel C. Ewing wrote: 
  
  If the real requirement is that the parameter address must point to a 
  location containing what the PoOp describes as a half-word binary value, 
  then the manual should state precisely that. 
  
  Thanks for bringing this thread back to my original concern when I 
  started it (I never imagined! ...), however interesting the digressions 
  to HFP and ternary logic may be, and for stating that concern more 
  clearly than I did. 
  
  There should also be mention of the allowable range of values: 
  0n=32760?  0n=BLKSIZE?  0ntrack-size?  0n=65535? 
  (The last is the maximum supported by channel programs, or was.) 
  Are unsigned halfwords supported?  This became an issue about the 
  advent of the 3380. 
  
  Clearly the present text of the manual engenders confusion and 
  dissent. 
  
  -- 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 
 
 -- 
 For IBM-MAIN subscribe / signoff / archive access instructions, 
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-09 Thread Tony Harminc

On 9 December 2013 18:04, DASDBILL2 dasdbi...@comcast.net wrote:
 My phrase billions of CCWs was assuming you already knew how to read a full 
 track with only one CCW. A fully
 populated EAV can have 16 to the 7th power cylinders and each cylinder can 
 have 15 tracks.  One Read Track CCW
 (and not Read Multiple CKD, which is too primitive) per track would require 4 
 026 531 840 CCWs, which is four billion,
 which is billions.  And each CCW would need 56K bytes of real, fixed 
 storage for the life of this I/O request.  That's
 228 terabytes of real storage, which is the main reason why I called this 
 channel program theoretical.

In the real world, PCI would be used to modify the channel program on
the fly. It would presumably be copying the data to another device
(tape or disk), and as long as that output device could keep up,
there's no reason for this to be a theoretical-only scheme.

Much the same thing, on a smaller and slower scale (though perhaps not
much smaller relative to the hardware of the day) was done by APL\360
with its terminal I/O. The terminal read channel program was unending,
with new buffers being chained in based on PCI interrupts.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

t...@harminc.net (Tony Harminc) writes:
In the real world, PCI would be used to modify the channel program on
the fly. It would presumably be copying the data to another device
(tape or disk), and as long as that output device could keep up,
there's no reason for this to be a theoretical-only scheme.

Much the same thing, on a smaller and slower scale (though perhaps not
much smaller relative to the hardware of the day) was done by APL\360
with its terminal I/O. The terminal read channel program was unending,
with new buffers being chained in based on PCI interrupts.

re:
http://www.garlic.com/~lynn/2013o.html#6 hexadecimal?
http://www.garlic.com/~lynn/2013o.html#10 hexadecimal?
http://www.garlic.com/~lynn/2013o.html#12 hexadecimal?

with the advent of virtual memory and EXCP no longer executing the
passed channel program ... but a copied that had been swizzled
(replacing virtual addresses with current real addresses, virtual
addresses possibly contiguous ... but the corresponding pages in real
storage no longer contiguous, etc) ... the PCI appendage wouldn't
be modifying the channel program actually in use

EXCPVR was created for authorized code to create real CCWs with real
addresses (doing the necessary work to deal with real addresses
rather than real addresses)
http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.idas300/efcprs.htm#efcprs

from above:

Fix the data area containing your channel program, the data areas
referred to by your channel program, the PCI appendage (if your program
can generate program-controlled interrupts), and any area referred to by
the PCI appendage including the DEB, IOB, etc. To fix these areas, build
a list in your PGFX appendage containing the addresses of these virtual
areas. Any area that you know already is in fixed storage for the
duration of the I/O can be omitted from the page fix list.

... snip ...

cp67 vm370 might do long, channel program with multiple page transfers
... especially fixed-head devices. For really long channel programs, I
would add periodic PCI interrupts to allow more timely processing of
pages already transferred ... w/o waiting for the complete channel
program to end (but it didn't involve modifying channel programs in
progress).

original cp67 delivered to the univ. had a FIFO queue of page i/o
requests and would do single transfer per channel program. This achieved
peak throughput of approx. 80 page transfer per second on 360/67 with
2301 fixed-head drum (avg. half revolution delay per page transfer). As
an undergraduate in the 60s, I modified that to chain together all
requests for arm position (or all queued requests for 2301 fixed-head
drum) to maximize transfers per revolution. This could get very close to
theoritical max. 270 page transfers second (3600rpm, 60rps, nine 4k
pages formated per pair of tracks, two revolutions per 9 4k page
transfers).

For 2311 2314 moveable arm disks, cp67 originally also did FIFO queue
processing ... at the same time I did the multiple request chaining
... i also added ordered arm seek queueing. The combination
significantly increased loaded I/O throughput ... and also made
degradation under heavy load much more graceful.

--
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-09 Thread David L. Craig

On 13Dec09:1528-0500, Gerhard Postpischil wrote:

 On 12/9/2013 2:56 PM, Skip Robinson wrote:
 
 2) That's a shame. Every programmer can benefit from familiarity
 with the hardware - write a test program using EXCP to read a
 multi-volume tape, or use XDAP to read a multi-volume DASD data set
 with unknown block sizes.
I remember Dr. Rannie talking about teaching Intro To Channel
Programming using XDAP, not EXCP, so the students wouldn't have
to worry about IOBs.  He was challenged to come up with any
other reason for using XDAP over EXCP.

Of course, real MVS programmers use STARTIO (unless they cannot
get their code into an APF library, of course). ;-)
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-08 Thread Charles Mills

It is a pet peeve of mine. People use hex sloppily to mean binary (what I 
think IBM means in your example) or non-printable (does it look like a DD 
name? Nyah, it's a bunch of hex.).

Hex is not a kind of data. It is a convenient way of representing data. X'F1' 
is a clearer image in most cases than 0001 or 241. All data is potentially 
hex; that is, is representable in hex. That's the beauty of hex. 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, December 07, 2013 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: hexadecimal?

From:

Title: z/OS V1R13.0 DFSMSdfp Advanced Services
Document Number: SC26-7400-14

... that I was reading lately:

7.5.3.1 TRKCALC--Standard Form
...
DD=addr--RX-type address, (2-12), (0), (14), or n
You can specify either the address of a field containing the
hexadecimal value of the record's data length, ...

Hexadecimal!?  Does this mean the value must be coded as hexadecimal display, 
e.g. C'50' to indicate 80?  Or must it be coded as a hexadecimal self-defining 
term (X'50')?  Why not a decimal self-defining term (80)?
Or a binary self-defining term (B'0101')?  Or even an A()-constant 
(AL2(100-20))?

Is hexadecimal otiose?  Is it time for an RCF?

(I've seen other uses of hexadecimal that I find otiose in MVS documentation. 
 I suspect a tech writer's mother was traumatized during gestation by 
hexadecimal notation.)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-08 Thread John McKown

Agree. I have not checked, but will bat this is really a full word integer
binary number.
 On Dec 8, 2013 11:43 AM, Charles Mills charl...@mcn.org wrote:

 It is a pet peeve of mine. People use hex sloppily to mean binary
 (what I think IBM means in your example) or non-printable (does it look
 like a DD name? Nyah, it's a bunch of hex.).

 Hex is not a kind of data. It is a convenient way of representing data.
 X'F1' is a clearer image in most cases than 0001 or 241. All data is
 potentially hex; that is, is representable in hex. That's the beauty of hex.

 Charles

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Paul Gilmartin
 Sent: Saturday, December 07, 2013 2:53 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: hexadecimal?

 From:

 Title: z/OS V1R13.0 DFSMSdfp Advanced Services
 Document Number: SC26-7400-14

 ... that I was reading lately:

 7.5.3.1 TRKCALC--Standard Form
 ...
 DD=addr--RX-type address, (2-12), (0), (14), or n
 You can specify either the address of a field containing the
 hexadecimal value of the record's data length, ...

 Hexadecimal!?  Does this mean the value must be coded as hexadecimal
 display, e.g. C'50' to indicate 80?  Or must it be coded as a hexadecimal
 self-defining term (X'50')?  Why not a decimal self-defining term (80)?
 Or a binary self-defining term (B'0101')?  Or even an A()-constant
 (AL2(100-20))?

 Is hexadecimal otiose?  Is it time for an RCF?

 (I've seen other uses of hexadecimal that I find otiose in MVS
 documentation.  I suspect a tech writer's mother was traumatized during
 gestation by hexadecimal notation.)

 --
 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: hexadecimal?

2013-12-08 Thread John Gilmore

Charles Mills wrote

| Hex is not a kind of data.

and I think we all sympathize with the point he is making.  There is,
however, some real hexadecimal data around, beginning with its use in
IBM 7090 channel programming.  For the System/360 and its sequelæ the
exponent of an HFP number is represented in storage as a (biased)
hexadecimal number and operated upon using hexadecimal arithmetic.
(This is the rationale for the PL/I characterization of a fullword,
single-precision HFP value as binary float (21) and not binary
float(24) although the mantissa does in fact contain 24 bits.)

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-08 Thread Gerhard Postpischil


On 12/8/2013 12:52 PM, John McKown wrote:

Agree. I have not checked, but will bat this is really a full word integer
binary number.


Minor nit - DD= specifies a halfword.


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

On 13Dec08:0942-0800, Charles Mills wrote:

 It is a pet peeve of mine. People use hex sloppily
 to mean binary (what I think IBM means in your
 example) or non-printable (does it look like a DD
 name? Nyah, it's a bunch of hex.).
 
 Hex is not a kind of data. It is a convenient way of
 representing data. X'F1' is a clearer image in most
 cases than 0001 or 241. All data is potentially
 hex; that is, is representable in hex. That's the
 beauty of hex.

I would not expect to read this on this maining list.
The original floating-point hardware of the S/360
architecture is hexadecimal, not binary.  A normalized
value may have up to three leading binary zeros as a
consequence.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

Huh .maybe you should back to computer basics ...at machine level 
everything is binary

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 1:44 PM, David L. Craig dlc@gmail.com wrote:
 
 On 13Dec08:0942-0800, Charles Mills wrote:
 
 It is a pet peeve of mine. People use hex sloppily
 to mean binary (what I think IBM means in your
 example) or non-printable (does it look like a DD
 name? Nyah, it's a bunch of hex.).
 
 Hex is not a kind of data. It is a convenient way of
 representing data. X'F1' is a clearer image in most
 cases than 0001 or 241. All data is potentially
 hex; that is, is representable in hex. That's the
 beauty of hex.
 
 I would not expect to read this on this maining list.
 The original floating-point hardware of the S/360
 architecture is hexadecimal, not binary.  A normalized
 value may have up to three leading binary zeros as a
 consequence.
 -- 
 not cent from sell
 May the LORD God bless you exceedingly abundantly!
 
 Dave_Craig__
 So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
 __--from_Nightfall_by_Asimov/Silverberg_
 
 --
 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: hexadecimal?

2013-12-08 Thread Warren Brown

So , hexadecimal is not the same EBCDIC ?

 From: David L. Craig dlc@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Sunday, December 8, 2013 1:44 PM
Subject: Re: hexadecimal?

On 13Dec08:0942-0800, Charles Mills wrote:

 It is a pet peeve of mine. People use hex sloppily
 to mean binary (what I think IBM means in your
 example) or non-printable (does it look like a DD
 name? Nyah, it's a bunch of hex.).

 Hex is not a kind of data. It is a convenient way of
 representing data. X'F1' is a clearer image in most
 cases than 0001 or 241. All data is potentially
 hex; that is, is representable in hex. That's the
 beauty of hex.

I would not expect to read this on this maining list.
The original floating-point hardware of the S/360
architecture is hexadecimal, not binary.  A normalized
value may have up to three leading binary zeros as a
consequence.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
You'd better rearrange your beliefs, then.
Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

--
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: hexadecimal?

Hexadecimal is a readable system for binary, if the hex characters are not 
numbers per se they are EBCDIC...that's been since I wrote BAL on s360/20

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 1:55 PM, Warren Brown war...@att.net wrote:
 
 So , hexadecimal is not the same EBCDIC ?
 
 
 
 From: David L. Craig dlc@gmail.com
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Sunday, December 8, 2013 1:44 PM
 Subject: Re: hexadecimal?
 
 
 On 13Dec08:0942-0800, Charles Mills wrote:
 
 It is a pet peeve of mine. People use hex sloppily
 to mean binary (what I think IBM means in your
 example) or non-printable (does it look like a DD
 name? Nyah, it's a bunch of hex.).
 
 Hex is not a kind of data. It is a convenient way of
 representing data. X'F1' is a clearer image in most
 cases than 0001 or 241. All data is potentially
 hex; that is, is representable in hex. That's the
 beauty of hex.
 
 I would not expect to read this on this maining list.
 The original floating-point hardware of the S/360
 architecture is hexadecimal, not binary.  A normalized
 value may have up to three leading binary zeros as a
 consequence.
 -- 
 not cent from sell
 May the LORD God bless you exceedingly abundantly!
 
 Dave_Craig__
 So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
 __--from_Nightfall_by_Asimov/Silverberg_
 
 --
 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: hexadecimal?

Circuits talk 1s and 0s ...not hex

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 1:58 PM, Scott Ford scott_j_f...@yahoo.com wrote:
 
 Hexadecimal is a readable system for binary, if the hex characters are not 
 numbers per se they are EBCDIC...that's been since I wrote BAL on s360/20
 
 Scott ford
 www.identityforge.com
 from my IPAD
 
 'Infinite wisdom through infinite means'
 
 
 On Dec 8, 2013, at 1:55 PM, Warren Brown war...@att.net wrote:
 
 So , hexadecimal is not the same EBCDIC ?
 
 
 
 From: David L. Craig dlc@gmail.com
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Sunday, December 8, 2013 1:44 PM
 Subject: Re: hexadecimal?
 
 
 On 13Dec08:0942-0800, Charles Mills wrote:
 
 It is a pet peeve of mine. People use hex sloppily
 to mean binary (what I think IBM means in your
 example) or non-printable (does it look like a DD
 name? Nyah, it's a bunch of hex.).
 
 Hex is not a kind of data. It is a convenient way of
 representing data. X'F1' is a clearer image in most
 cases than 0001 or 241. All data is potentially
 hex; that is, is representable in hex. That's the
 beauty of hex.
 
 I would not expect to read this on this maining list.
 The original floating-point hardware of the S/360
 architecture is hexadecimal, not binary.  A normalized
 value may have up to three leading binary zeros as a
 consequence.
 -- 
 not cent from sell
 May the LORD God bless you exceedingly abundantly!
 
 Dave_Craig__
 So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
 __--from_Nightfall_by_Asimov/Silverberg_
 
 --
 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: hexadecimal?

On 13Dec08:1352-0500, Scott Ford wrote:

 Huh .maybe you should back to computer basics
 ...at machine level everything is binary
 
 Scott ford
 www.identityforge.com
 from my IPAD

You, sir, are the one who needs to go back--specifically
to zPOPs page 9-3:

: Hexadecimal-Floating-Point (HFP)
: 
: Hexadecimal-floating-point (HFP) operands have for-
: mats which provide for exponents that specify pow-
: ers of the radix 16 and significands that are
: hexadecimal numbers. The exponent range is the
: same for the short, long, and extended formats. The
: results of most operations on HFP data are truncated
: to fit into the target format, but there are instructions
: available to round the result when converting to a
: narrower format. For HFP operands, the implicit unit
: digit of the significand is always zero. Since the value
: of the significand and fraction are the same, HFP
: operations are described in terms of the fraction, and
: the term significand is not used.
: 
: Either normalized or unnormalized numbers may be
: used as operands for any HFP or DFP operation,
: where, for HFP, a normalized number is one having a
: nonzero leftmost fraction digit, or, for DFP, a normal-
: ized number is one having a nonzero leftmost signifi-
: cand digit. Most HFP instructions generate
: normalized results for greatest precision. HFP add
: and subtract instructions that generate unnormalized
: results are also available.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

What do circuits work in  ...

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 2:07 PM, David L. Craig dlc@gmail.com wrote:
 
 On 13Dec08:1352-0500, Scott Ford wrote:
 
 Huh .maybe you should back to computer basics
 ...at machine level everything is binary
 
 Scott ford
 www.identityforge.com
 from my IPAD
 
 You, sir, are the one who needs to go back--specifically
 to zPOPs page 9-3:
 
 : Hexadecimal-Floating-Point (HFP)
 : 
 : Hexadecimal-floating-point (HFP) operands have for-
 : mats which provide for exponents that specify pow-
 : ers of the radix 16 and significands that are
 : hexadecimal numbers. The exponent range is the
 : same for the short, long, and extended formats. The
 : results of most operations on HFP data are truncated
 : to fit into the target format, but there are instructions
 : available to round the result when converting to a
 : narrower format. For HFP operands, the implicit unit
 : digit of the significand is always zero. Since the value
 : of the significand and fraction are the same, HFP
 : operations are described in terms of the fraction, and
 : the term significand is not used.
 : 
 : Either normalized or unnormalized numbers may be
 : used as operands for any HFP or DFP operation,
 : where, for HFP, a normalized number is one having a
 : nonzero leftmost fraction digit, or, for DFP, a normal-
 : ized number is one having a nonzero leftmost signifi-
 : cand digit. Most HFP instructions generate
 : normalized results for greatest precision. HFP add
 : and subtract instructions that generate unnormalized
 : results are also available.
 -- 
 not cent from sell
 May the LORD God bless you exceedingly abundantly!
 
 Dave_Craig__
 So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
 __--from_Nightfall_by_Asimov/Silverberg_
 
 --
 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: hexadecimal?

On 13Dec08:1428-0500, Scott Ford wrote:

 What do circuits work in  ...

Sigh... I suggest you discuss it with Gene Amdahl, not me.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

Then suggest you don't come out guns blazing , unless they are loaded, because 
you don't have a clue

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 2:35 PM, David L. Craig dlc@gmail.com wrote:
 
 On 13Dec08:1428-0500, Scott Ford wrote:
 
 What do circuits work in  ...
 
 Sigh... I suggest you discuss it with Gene Amdahl, not me.
 -- 
 not cent from sell
 May the LORD God bless you exceedingly abundantly!
 
 Dave_Craig__
 So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
 __--from_Nightfall_by_Asimov/Silverberg_
 
 --
 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: hexadecimal?

Btw this isn't a Amdahl forum, it's IBM...

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 2:38 PM, Scott Ford scott_j_f...@yahoo.com wrote:
 
 Then suggest you don't come out guns blazing , unless they are loaded, 
 because you don't have a clue
 
 Scott ford
 www.identityforge.com
 from my IPAD
 
 'Infinite wisdom through infinite means'
 
 
 On Dec 8, 2013, at 2:35 PM, David L. Craig dlc@gmail.com wrote:
 
 On 13Dec08:1428-0500, Scott Ford wrote:
 
 What do circuits work in  ...
 
 Sigh... I suggest you discuss it with Gene Amdahl, not me.
 -- 
 not cent from sell
 May the LORD God bless you exceedingly abundantly!
 
 Dave_Craig__
 So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
 __--from_Nightfall_by_Asimov/Silverberg_
 
 --
 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: hexadecimal?

2013-12-08 Thread Peter Sylvester


On 12/08/2013 08:07 PM, David L. Craig wrote:

On 13Dec08:1352-0500, Scott Ford wrote:


Huh .maybe you should back to computer basics
...at machine level everything is binary


You, sir, are the one who needs to go back--specifically
to zPOPs page 9-3:

please :-)

- look into wikipedia about the meaning of hexadecimal

- HPF  magnitude is the product of the significant and the radix powered to the 
exponent
  the significant is a sequence of bits
  the representation table in 9-6 shows what happens when you divide
 (1 - 0.5 - 1/64)
  the table does not use a hexadecimal representation
  if you change the exponent in an hfp by one, you need to shift
  the signicant by four bits to roughly get the same number (~ 
rounding/overflow)
  thus it seems convenient to think about the radix 16 significant as a
  sequence of hexadecimal numbers (which would then be shifted by 1)

- =X'ABCD' in BAL is still a representation of 16 bits.


best regards
Peter Sylvester





: results are also available.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-08 Thread John McKown

Amdahl was the main architect of the S/360. So I guess we can mention him
on occasion.
On Dec 8, 2013 1:41 PM, Scott Ford scott_j_f...@yahoo.com wrote:

 Btw this isn't a Amdahl forum, it's IBM...

 Scott ford
 www.identityforge.com
 from my IPAD

 'Infinite wisdom through infinite means'


  On Dec 8, 2013, at 2:38 PM, Scott Ford scott_j_f...@yahoo.com wrote:
 
  Then suggest you don't come out guns blazing , unless they are loaded,
 because you don't have a clue
 
  Scott ford
  www.identityforge.com
  from my IPAD
 
  'Infinite wisdom through infinite means'
 
 
  On Dec 8, 2013, at 2:35 PM, David L. Craig dlc@gmail.com
 wrote:
 
  On 13Dec08:1428-0500, Scott Ford wrote:
 
  What do circuits work in  ...
 
  Sigh... I suggest you discuss it with Gene Amdahl, not me.
  --
  not cent from sell
  May the LORD God bless you exceedingly abundantly!
 
  Dave_Craig__
  So the universe is not quite as you thought it was.
  You'd better rearrange your beliefs, then.
  Because you certainly can't rearrange the universe.
  __--from_Nightfall_by_Asimov/Silverberg_
 
  --
  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: hexadecimal?

2013-12-08 Thread Ed Finnell

Sleigh bells ring...We had an ol' V8 in the basement that only did SWIFT.  
It queued the requests until it got to a billion then would do the transfer. 
 We'd get the float on the interim. Good solid revenue producer. Then one 
day it  'thermalled'. They had boxes and boxes of components trucked in from 
Sunnyvale.  Still took about 22hrs to get it back online. There were so many 
'suits'  wandering around the OPs manager came and said 'Listen up, if 
you're not a CE  you'll be escorted out!' 
 
In a tight budget, amazing how fast funds can be found to reduce single  
points of failure! 
 
 
In a message dated 12/8/2013 2:05:56 P.M. Central Standard Time,  
john.archie.mck...@gmail.com writes:

Amdahl  was the main architect of the S/360. So I guess we can mention him
on  occasion.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-08 Thread Robert A. Rosenberg


At 10:55 -0800 on 12/08/2013, Warren Brown wrote about Re: hexadecimal?:


So , hexadecimal is not the same EBCDIC ?


Data in the computer is stored in 8-bit long bytes. Hex is a way of 
displaying the contents of the bytes as two characters representing 
the value of the first and second set of 4 bits. EBCDIC is a mapping 
of Glyphs into one of 256 values. Thus the glyph 1 is mapped to the 
value 241 or XF1.


 From: David L. Craig 
dlc@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, 
December 8, 2013 1:44 PM Subject: Re: hexadecimal? On 
13Dec08:0942-0800, Charles Mills wrote:  It is a pet peeve of mine. 
People use hex sloppily  to mean binary (what I think IBM means 
in your  example) or non-printable (does it look like a DD  
name? Nyah, it's a bunch of hex.).   Hex is not a kind of data. 
It is a convenient way of  representing data. X'F1' is a clearer 
image in most  cases than 0001 or 241. All data is 
potentially  hex; that is, is representable in hex. That's the  
beauty of hex. I would not expect to read this on this maining list. 
The original floating-point hardware of the S/360 architecture is 
hexadecimal, not binary.  A normalized value may have up to three 
leading binary zeros as a consequence. -- not cent from sell May 
the LORD God bless you exceedingly abundantly! 
Dave_Craig__ So the 
universe is not quite as you thought it was. You'd better rearrange 
your beliefs, then. Because you certainly can't rearrange the 
universe. __--from_Nightfall_by_Asimov/Silverberg_ 
-- 
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: hexadecimal?

John,

I agree but you can't compare apples and oranges ...right ? I don't know that 
much about Amdahl nor am I trying give the Gentleman a hard time. But 
hexadecimal, excuse me? 

Circuits work with 1s and 0s and Assembler, Cobol, etc translate into machine 
code which is binary .maybe I am over - reacting , if so I am sorry

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 3:05 PM, John McKown john.archie.mck...@gmail.com wrote:
 
 Amdahl was the main architect of the S/360. So I guess we can mention him
 on occasion.
 On Dec 8, 2013 1:41 PM, Scott Ford scott_j_f...@yahoo.com wrote:
 
 Btw this isn't a Amdahl forum, it's IBM...
 
 Scott ford
 www.identityforge.com
 from my IPAD
 
 'Infinite wisdom through infinite means'
 
 
 On Dec 8, 2013, at 2:38 PM, Scott Ford scott_j_f...@yahoo.com wrote:
 
 Then suggest you don't come out guns blazing , unless they are loaded,
 because you don't have a clue
 
 Scott ford
 www.identityforge.com
 from my IPAD
 
 'Infinite wisdom through infinite means'
 
 
 On Dec 8, 2013, at 2:35 PM, David L. Craig dlc@gmail.com
 wrote:
 
 On 13Dec08:1428-0500, Scott Ford wrote:
 
 What do circuits work in  ...
 
 Sigh... I suggest you discuss it with Gene Amdahl, not me.
 --
 not cent from sell
 May the LORD God bless you exceedingly abundantly!
 
 Dave_Craig__
 So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
 __--from_Nightfall_by_Asimov/Silverberg_
 
 --
 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: INFO IBM-MAIN

Re: hexadecimal?

2013-12-08 Thread John McKown

Ah, my mistake. Digital (binary) computers do deal in 0s and 1s. Analog
computers did not, but that's all I know about them.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-08 Thread John Gilmore

The system/360 and its mainframe successors are largely binary
machines.  In particular, addressing is entirely binary.  They can,
however, do both decimal and hexadecimal arithmetic in some situations
too.

All this can be reduced to boolean algebra and, finally, to assorted
configurations of NORs or NANDs: binary arithmetic can indeed be made
to disappear, replaced by boolean algebra.  These reductions are
theoretically important; but, as I have had occasion to point out here
before, you can cut yourself with Ockham's razor.

In most cases it is appropriate, qua programmer although not perhaps
qua circuit designer, to think of the z/Architecture HFP instructions
as doing hexadecimal arithmetic and of the decimal and DFP
instructions as doing decimal arithmetic

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

John,

I understand the z/arch somewhat, I stepped out of the hardware arena many 
moons ago, my father was involved with hardware at Unisys. I was taught every 
converted down to its lowest common factor, binary..are you saying otherwise ? 
You comments I understand somewhat but I am a practical guy ..so help me 
understand here

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 4:39 PM, John Gilmore jwgli...@gmail.com wrote:
 
 The system/360 and its mainframe successors are largely binary
 machines.  In particular, addressing is entirely binary.  They can,
 however, do both decimal and hexadecimal arithmetic in some situations
 too.
 
 All this can be reduced to boolean algebra and, finally, to assorted
 configurations of NORs or NANDs: binary arithmetic can indeed be made
 to disappear, replaced by boolean algebra.  These reductions are
 theoretically important; but, as I have had occasion to point out here
 before, you can cut yourself with Ockham's razor.
 
 In most cases it is appropriate, qua programmer although not perhaps
 qua circuit designer, to think of the z/Architecture HFP instructions
 as doing hexadecimal arithmetic and of the decimal and DFP
 instructions as doing decimal arithmetic
 
 John Gilmore, Ashland, MA 01721 - USA
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

On 13Dec08:0942-0800, Charles Mills wrote:

 Hex is not a kind of data. It is a convenient way of
 representing data. X'F1' is a clearer image in most
 cases than 0001 or 241. All data is potentially
 hex; that is, is representable in hex. That's the
 beauty of hex.

This is the paragraph I took (and still take) exception
to.  Before you assert the S/360 was digitally 100%
binary you need to review all the schematics to ensure
there aren't any non-binary components; e.g., three-state
logic gates.  Such is a question IBM Fellow Amdahl or any
competent CE can address.  But this is an area that even
the microcode could be ignorant of.  A BAL programmer had
better deal with what the POPs document.  If you program
HFP instructions as if your are dealing with IEEE hardware
your results are likely to become problematic at some
point.  At minimum, HFP documents a hexadecimal kind of
data and I rest my case.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

David:
 
I don't know what your profession is , but in 40+ yrs and about 20+ shops, many 
in the NYC area and very very aggressive with their applications, including 
z/OS, VM and VSE , I never ever had to worry about it ..Give me an example of 
such  a concern ?
 
BTW I have been commercially developing software for 10+ years the other years 
with some of the world's biggest companies..
 
I am trying to understand your point . I see fluff, where's the example, real 
world, maybe NASA or JPL or some government IBM software installation, I will 
give you that ...

Scott J Ford
Software Engineer
http://www.identityforge.com/
 



On Sunday, December 8, 2013 5:41 PM, David L. Craig dlc@gmail.com wrote:
  
On 13Dec08:0942-0800, Charles Mills wrote:

 Hex is not a kind of data. It is a convenient way of
 representing data. X'F1' is a clearer image in most
 cases than 0001 or 241. All data is potentially
 hex; that is, is representable in hex. That's the
 beauty of hex.

This is the paragraph I took (and still take) exception
to.  Before you assert the S/360 was digitally 100%
binary you need to review all the schematics to ensure
there aren't any non-binary components; e.g., three-state
logic gates.  Such is a question IBM Fellow Amdahl or any
competent CE can address.  But this is an area that even
the microcode could be ignorant of.  A BAL programmer had
better deal with what the POPs document.  If you program
HFP instructions as if your are dealing with IEEE hardware
your results are likely to become problematic at some
point.  At minimum, HFP documents a hexadecimal kind of
data and I rest my case.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
You'd better rearrange your beliefs, then.
Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_


--
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: hexadecimal?

On 13Dec08:1647-0500, Scott Ford wrote:

  On Dec 8, 2013, at 4:39 PM, John Gilmore jwgli...@gmail.com wrote:
  
  The system/360 and its mainframe successors are largely binary
  machines.  In particular, addressing is entirely binary.  They can,
  however, do both decimal and hexadecimal arithmetic in some situations
  too.
  
  All this can be reduced to boolean algebra and, finally, to assorted
  configurations of NORs or NANDs: binary arithmetic can indeed be made
  to disappear, replaced by boolean algebra.  These reductions are
  theoretically important; but, as I have had occasion to point out here
  before, you can cut yourself with Ockham's razor.
  
  In most cases it is appropriate, qua programmer although not perhaps
  qua circuit designer, to think of the z/Architecture HFP instructions
  as doing hexadecimal arithmetic and of the decimal and DFP
  instructions as doing decimal arithmetic
 
 I understand the z/arch somewhat, I stepped out
 of the hardware arena many moons ago, my father
 was involved with hardware at Unisys. I was taught
 every converted down to its lowest common factor,
 binary..are you saying otherwise ? You comments I
 understand somewhat but I am a practical guy ..so
 help me understand here

Boolean algebra is a mathematics based upon variables
that can take on only two possible values.  IIRC, the
Soviets were rumored to have probed the attributes
of trinary-state computing in the '60s or '70s and
discontinued the research, but I have not located a
source to confirm even the rumor.  Maybe Lynn Wheeler
has it in his archives.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

2013-12-08 Thread Paul Gilmartin

On Sun, 8 Dec 2013 18:01:01 -0500, David L. Craig wrote:

Boolean algebra is a mathematics based upon variables
that can take on only two possible values.  IIRC, the
Soviets were rumored to have probed the attributes
of trinary-state computing in the '60s or '70s and
discontinued the research, but I have not located a
source to confirm even the rumor.  Maybe Lynn Wheeler
has it in his archives.
 
For a start:

http://en.wikipedia.org/wiki/Ternary_computer

GIYF,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

On 13Dec08:1449-0800, Scott Ford wrote:

 I don't know what your profession is , but in 40+
 yrs and about 20+ shops, many in the NYC area and very
 very aggressive with their applications, including
 z/OS, VM and VSE , I never ever had to worry about it
 ..Give me an example of such  a concern ?

Back in the early '70s when I was a mere OS/MVT/HASP
operator, I developed an assembler program to process
FORTRAN statements containing literal non-integers.
Converting C'123.45' into its HFP equivalent or back
may not be something you ever needed to develop.

 BTW I have been commercially developing software
 for 10+ years the other years with some of the world's
 biggest companies..

I'd rather not run the risk of violating listserv policy
by posting details, but you should be able to find my
career details online if it really matters to you.

 I am trying to understand your point . I see fluff,
 where's the example, real world, maybe NASA or JPL or
 some government IBM software installation, I will give
 you that ...

The NASA Goddard GRTS system certainly had such concerns
but I was only responsible for the virtual machine in
which it ran.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: hexadecimal?

David,

For one I am not trying to bust your chops as we say up here in the Northeast. 
But remember we are all products of school and experience. Because I haven't 
seen it doesn't mean it doesn't exist. But I have the experience of ppl making 
off the wall comments with no knowledge or experience to backup their comments, 
sales talk , whatever. I am a techie I know what I see and experience.

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 8, 2013, at 6:25 PM, David L. Craig dlc@gmail.com wrote:
 
 On 13Dec08:1449-0800, Scott Ford wrote:
 
 I don't know what your profession is , but in 40+
 yrs and about 20+ shops, many in the NYC area and very
 very aggressive with their applications, including
 z/OS, VM and VSE , I never ever had to worry about it
 ..Give me an example of such  a concern ?
 
 Back in the early '70s when I was a mere OS/MVT/HASP
 operator, I developed an assembler program to process
 FORTRAN statements containing literal non-integers.
 Converting C'123.45' into its HFP equivalent or back
 may not be something you ever needed to develop.
 
 BTW I have been commercially developing software
 for 10+ years the other years with some of the world's
 biggest companies..
 
 I'd rather not run the risk of violating listserv policy
 by posting details, but you should be able to find my
 career details online if it really matters to you.
 
 I am trying to understand your point . I see fluff,
 where's the example, real world, maybe NASA or JPL or
 some government IBM software installation, I will give
 you that ...
 
 The NASA Goddard GRTS system certainly had such concerns
 but I was only responsible for the virtual machine in
 which it ran.
 -- 
 not cent from sell
 May the LORD God bless you exceedingly abundantly!
 
 Dave_Craig__
 So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
 __--from_Nightfall_by_Asimov/Silverberg_
 
 --
 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: hexadecimal?