subject:"FBA rant"


Andreas F. Geissbuehler wrote:
The venerable IBM 2321 A.K.A the strip picker, the one responsible for 
the mbb in mbbcchhr -- did CP/67 or VM ever support the 2321 ?


re:
http://www.garlic.com/~lynn/2007e.html#51 FBA rant

addenda and more topic drift.

the reason given for periodically roping me into playing disk engineer was that
so many senior engineers had departed (lots in the departure to memorex and then
various others including later departures to storage tek). they needed somebody
that understood i/o architecture at a high level ... which had been the 
responsibility
of the senior engineers that had left. i got pulled into it because of having to
get into the guts of i/o architecture as part of being able to make the 
virtualization
work correctly ... and then i got pulled into other areas. lots of past posts
mentioning getting to play in disk engineering and product test labs
http://www.garlic.com/~lynn/subtopic.html#disk

recent post in this thread mentioning getting to play disk engineer
http://www.garlic.com/~lynn/2007e.html#40 FBA rant

I did later run into one of the disk engineers that had been part of the group 
that
had departed for memorex and claimed to have done a lot of the work on 2321. He
and some others at memorex had left and founded their own company that did 
hardware
database engine. They had picked up a CTO out of Berkeley. When the CTO left 
their
company for Teradata (and then later founded his own rdbms company), they came
around san jose plant site looking to backfill the CTO position (primarily from 
people
working on system/r) . Similar to the stories told about Shugart recruiting around 
san jose plant site (after he had left) ... but on much smaller scale (and they did

manage to catch somebody to backfill the CTO position). lots of past posts 
mentioning
system/r
http://www.garlic.com/~lynn/subtopic.html#systemr

and other discussions around that era from the '95 SQL reunion:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Teradata.html

and recent post in original thread (from which this thread spawned)
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems 
history

misc. past posts mentioning shugart, floppy disks, departing for memorex, etc
http://www.garlic.com/~lynn/2000.html#9 Computer of the century
http://www.garlic.com/~lynn/2002.html#17 index searching
http://www.garlic.com/~lynn/2002l.html#50 IBM 2311 disk drive actuator and head 
assembly
http://www.garlic.com/~lynn/2004.html#5 The BASIC Variations
http://www.garlic.com/~lynn/2004j.html#36 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004p.html#0 Relational vs network vs hierarchic 
databases
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical 
cores?
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2005c.html#9 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005h.html#37 Software for IBM 360/30
http://www.garlic.com/~lynn/2006n.html#30 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After 
Multi-Core?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
 
In a message dated 3/8/2007 9:50:22 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
Andreas F. Geissbuehler wrote:
The venerable IBM 2321 A.K.A the strip picker, the one responsible  for the 
mbb in mbbcchhr -- did CP/67 or VM ever support the 2321  ?
 
The 2321 was only responsible for the bb part of the mbbcchhr.  The m  was, 
and still is, the extent number in the DEB.
 
Bill  Fairchild
Plainfield, IL

Criticism and dissent are the indispensable  antidote to major delusions. 
[Alan Barth, 1951; The Loyalty of Free  Men]


BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant


IBM Mainframe Discussion List wrote:
The 2321 was only responsible for the bb part of the mbbcchhr.  The m  was, 
and still is, the extent number in the DEB.
 
Bill  Fairchild

Plainfield, IL


i.e. seek CCW has six byte length ... bbcchh

CKD DASD command codes ... from my qd conversion of gcard ios3270 to html
(seek has count/length of 6):
http://www.garlic.com/~lynn/gcard.html#26.1

pictures of 2321 here:
http://members.optushome.com.au/intaretro/2321DCD.htm
http://www.columbia.edu/acis/history/datacell.html

in the above you can see bin closeup ... BB selection could
rotate the whole cylinder to place correct bin under the 
read/write heads ... rotation  somewhat would reminded me of 
washing machine.


past posts mentioning 2321 in this thread:
http://www.garlic.com/~lynn/2007e.html#51 FBA rant
http://www.garlic.com/~lynn/2007e.html#63 FBA rant

there is some slight physical packaging resemblance between 2321 and 2301 drum 
... both
appearing to be cylinders. 2301 drum can be seen here in mid-background to the 
right
of the tape-drives.
http://www.columbia.edu/acis/history/2311.html

another system picture with 2301 in mid-background
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/29.jpg

close-up here
http://www.columbia.edu/acis/history/drum.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
 
In a message dated 3/8/2007 11:44:21 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
seek CCW has six byte length ... bbcchh
 
Right.  And what device, other than the 2321, ever had meaningful  non-zero 
values for the bb part of bbcchh?  In other words, if there  had never been any 
2321, why would we have needed the extra 2 bytes for the bb  in seek and 
search addresses?
 
Bill  Fairchild
Plainfield, IL

Criticism and dissent are the indispensable  antidote to major delusions. 
[Alan Barth, 1951; The Loyalty of Free  Men]


BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant


[EMAIL PROTECTED] wrote:
Right.  And what device, other than the 2321, ever had meaningful  non-zero 
values for the bb part of bbcchh?  In other words, if there  had never been any 
2321, why would we have needed the extra 2 bytes for the bb  in seek and 
search addresses?


re:
http://www.garlic.com/~lynn/2007e.html#64 FBA rant

for other drift ... if the geometry characteristics were to be ignored then you 
could treat
the six byte seek argument as the track number (allowing the device to 
interpret the physical
characteristics ... somewhat similar to what FBA does in the locate command for 
the record
number).

i.e. CKD seek command is six byte field
http://www.garlic.com/~lynn/gcard.html#26.1

treated as purely a 2**48 bit numeric would allow for nearly 300 trillion tracks

and FBA locate command
http://www.garlic.com/~lynn/gcard.html#26.2

is eight byte number, which could allow for 2**64 512-byte records (i.e. 2**9 
times 2**64 bytes,
2**73 bytes per device)

for something complete different, quicky search engine use turned up this (IBM) 
patent
reference on mapping tof CKD to native FBA hardware
http://www.patentstorm.us/patents/6112277-description.html

and title of above:

Method and means for reducing device contention by random accessing 
and partial track staging of records according to a first DASD format 
but device mapped according to a second DASD format


... snip ...

The above patent also references another patent:

Reference should be made to Menon, U.S. Pat. No. 5,301,304, Emulating 
Records in One Record Format in Another Record Format, issued Apr. 5, 
1994. Menon exemplifies the state of the art in format conversion disclosing 
an emulation method for rapidly accessing CKD records in which the CKD records 
are stored on a disk drive in FBA format. 


... snip ...

now as suggested in previous post
http://www.garlic.com/~lynn/2007e.html#46 FBA rant

what would be the difficulty in modifying whatever MVS calls its current
incantation of CCWTRANS ... to morph application space EXCP CCWs that
are still doing things like multi-track VTOC/PDS search into FBA operations
... aka there are hardware control units and hypervisor software that
perform such morphing ... then if the original VS2 started out with
(cp67's) CCWTRANS moved into the VS2 kernel ... why can't more current
hypervisor technology be moved directly into the VS2 kernel

here is decade-plus old descriptive narative of ECKD (from vm mailing list) 
... basically discussing the retrofitting FBA-like channel commands to 
CKD architecture:

http://listserv.uark.edu/scripts/wa.exe?A2=ind9604L=ibmvmT=0P=9321

from above:

ECKD channel programs completely describe the nature and scope of data
transfer operation before the first data transfer command is executed.
These predictive channel programs remove all possible surprise from
the storage subsystem during data transfer operations. Like Fixed-Block
Architecture (FBA) DASD, ECKD uses the DEFINE EXTENT channel command to
delimit the range of tracks which may be affected by a channel program.
ECKD is still CKD: each record can contain Count, Key, and Data areas.
However, the count need not be CCHHR, as on conventional CKD DASD; one
could number the records sequentially, like FBA blocks.

... snip ...

as opposed to post
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
with my nearly 25yr old email commenting on ECKD
http://www.garlic.com/~lynn/2007e.html#email820907

slightly older random email reference to CALYPSO and ECKD ... in the
following DMKTRD is the vm370 kernel module responsible for cp
trace command related to tracing virtual machine i/o and ccws.

To: wheeler
Date: 10/10/80  15:28:17 


Lynn,

The new DMKTRD will trace CALYSPO' new Define Extent and Locate Record
CCW's. A 16 byte argument is displayed on the trace, immediately below the
trace of the CCW itself

Fix was tested virtual VM under VM and will go on 31B at STL by next
Tuesday.

... snip ...


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
 
In a message dated 3/8/2007 2:50:24 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
 
re:  _http://www.garlic.com/~lynn/2007e.html#64_ 
(http://www.garlic.com/~lynn/2007e.html#64)   FBA rant
 
Please be more specific.  There are about 100 articles on that web  page.
 
for other drift ... if the geometry characteristics were to be  ignored then 
you could treat
the six byte seek argument as the track number  (allowing the device to 
interpret the physical
characteristics ... somewhat  similar to what FBA does in the locate command 
for the  record
number).
 
This is all quite true.  But this doesn't answer my  question.  If there had 
been no 2321, then why would we need the first two  bytes of the 6-byte seek 
address?  I find it hard to believe that IBM in  1964 envisioned the day 40+ 
years into the future when they would need more than  4 bytes to describe 
uniquely a track on one device.  Today I can see the  limit drawing close.  But 
not 
40 years ago.
 
i.e. CKD seek command is six byte field
_http://www.garlic.com/~lynn/gcard.html#26.1_ 
(http://www.garlic.com/~lynn/gcard.html#26.1) 
 
Please be more specific.  There is about 100 articles on that web  page.  The 
fact that a seek command has a 6-byte data field transferred is  not what I 
am asking about.  I stipulate 6.  I am asking why not  4?
 
and FBA locate command _http://www.garlic.com/~lynn/gcard.html#26.2_ 
(http://www.garlic.com/~lynn/gcard.html#26.2)  is  eight byte number, which 
could 
allow for 2**64 512-byte records (i.e. 2**9 times  2**64 bytes, 2**73 bytes per 
device)
 
All quite true.  But why did CKD (i.e., non-FBA) devices need  the two extra 
bytes called bb except for the 2321?
 
for something complete different, quicky search engine use turned up  this 
(IBM) patent
reference on mapping tof CKD to native FBA hardware
_http://www.patentstorm.us/patents/6112277-description.html_ 
(http://www.patentstorm.us/patents/6112277-description.html) 
 
Interesting, but I would rather stick to the subject I asked  about.
 
Reference should be made to Menon, U.S. Pat. No. 5,301,304,  Emulating 
Records in One Record Format in Another Record Format, issued  Apr. 5, 
1994. Menon exemplifies the state of the art in format conversion  disclosing 
an emulation method for rapidly accessing CKD records in which  the CKD 
records 
are stored on a disk drive in FBA format.
 
The bb was invented ca. 1964, not 1994. Why was there a bb except for the  
2321?
 
now as suggested in previous  post
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
what would be the difficulty in modifying whatever MVS calls its  current
incantation of CCWTRANS ... to morph application space EXCP CCWs  that
are still doing things like multi-track VTOC/PDS search into FBA  operations
... aka there are hardware control units and hypervisor software  that
perform such morphing ... then if the original VS2 started out  with
(cp67's) CCWTRANS moved into the VS2 kernel ... why can't more  current
hypervisor technology be moved directly into the VS2  kernel
here is decade-plus old descriptive narative of ECKD (from vm mailing  list) 
... basically discussing the retrofitting FBA-like channel commands to  
CKD architecture:
_http://listserv.uark.edu/scripts/wa.exe?A2=ind9604L=ibmvmT=0P=9321_ 
(http://listserv.uark.edu/scripts/wa.exe?A2=ind9604L=ibmvmT=0P=9321) 
 
More wonderful details that do not address my one and only question.   The bb 
was invented long before ECKD and FBA.  Why, other than for the  2321?
 
ECKD channel programs completely describe the nature and scope of  data
transfer operation before the first data transfer command is  executed.
These predictive channel programs remove all possible surprise  from
the storage subsystem during data transfer operations. Like  Fixed-Block
Architecture (FBA) DASD, ECKD uses the DEFINE EXTENT channel  command to
delimit the range of tracks which may be affected by a channel  program.
ECKD is still CKD: each record can contain Count, Key, and Data  areas.
However, the count need not be CCHHR, as on conventional CKD DASD;  one
could number the records sequentially, like FBA blocks.
 
I know all that.  Why is there the bb part of the bbcchh except for  the 2321?
 
as opposed to post
http://www.garlic.com/~lynn/2007e.html#40 FBA  rant
with my nearly 25yr old email commenting on ECKD
_http://www.garlic.com/~lynn/2007e.html#email820907_ 
(http://www.garlic.com/~lynn/2007e.html#email820907) 
 
How about a post commenting on bb instead of things like ECKD, FBA, etc.  
etc.?
 
Bill  Fairchild
Plainfield, IL

Criticism and dissent are the indispensable  antidote to major delusions. 
[Alan Barth, 1951; The Loyalty of Free  Men]


BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email

Re: FBA rant

 
 
Much of this  FBA Rant thread that discusses a more better geometry is a 
repetition of posts  beginning around MAY 2005; e.g. this one:
_http://bama.ua.edu/cgi-bin/wa?A2=ind0507L=ibm-mainP=R61142I=3X=63346820B0
E4003BA4Y=DASDBILL2%40aol.com_ 
(http://bama.ua.edu/cgi-bin/wa?A2=ind0507L=ibm-mainP=R61142I=3X=63346820B0E4003BA4[EMAIL
 PROTECTED]) 
 
Plus ca change...
 
Bill  Fairchild
Plainfield, IL

Criticism and dissent are the indispensable  antidote to major delusions. 
[Alan Barth, 1951; The Loyalty of Free  Men]


BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

[EMAIL PROTECTED] writes:

Please be more specific. There are about 100 articles on that web page.

I'm not sure I understand your reference ... with respect to post ... copy here
at
http://www.garlic.com/~lynn/2007f.html#0 FBA rant

there is
http://www.garlic.com/~lynn/index.html

what has a number of URLs in different categories

including a pointer to html file:
http://www.garlic.com/~lynn/2007e.html

this particular HTML file has index with 66 articles (numeric
labels 0-65)

the specific URL I was referencing in the post was
http://www.garlic.com/~lynn/2007e.html#64

most browsers would position within the file at label 64. If your
browser isn't capable of handling a URL that includes positioning
within a file ... then the index at the front of file
http://www.garlic.com/~lynn/2007e.html

has 66 entries and 64 is the next to the last index entry (numbered
from zero). I'm not sure that will do you any good though ... since
if your browser can handle the original URL with relative position
... it also can't handle the relative URL in the index either.

Now there is another possibility that you may be having. I recently
updated file
http://www.garlic.com/~lynn/2007e.html

with most recent posts. If your browser has a earlier version of
2007e.html cached, that was obtained before the last couple postings
were added to the file ... then it would not be able to find the new
relative position (within the file as specified) and just position you
at the front of the file.

It also depends on how you may have configured your browser cache
settings ... some browsers have an option to check on consistency of
what is in the cache and the original either once per file after each
startup or check for consistency on every reference.

In any case, you usually can synchronize what might be in your browser
cache and the original file by hitting the reload button.

Now you repeat your same comment with respect to their being 100 articles on
that
web page ... and have used the comment both with respect to
http://www.garlic.com/~lynn/2007e.html#64
and
http://www.garlic.com/~lynn/gcard.html#26.1

Looking at the body of you post ... there seems to be some issue with whatever
you are
using that has trailing underscore on some flavors of URL ... I don't know
whether
your browser processor is adding that trailing underscore or not ... it doesn't
exist in the original.

Now, I can see where your browser might have a stale cached copy of 2007e.html ... and not being able to find relative href/name 64 within the file ... but the file gcard.html has had href/name of 26.1 since it was first made available ... so it would seem unlikely that you would have stale caching problems with both
http://www.garlic.com/~lynn/2007e.html#64

and
http://www.garlic.com/~lynn/gcard.html#26.1

not being able to find the relative position in both files. Possibly you are having
browser problems? Other possibility is possibly you have some DNS cache poisoning
and your browser isn't actually getting to my real web pages?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
 
In a message dated 3/8/2007 5:59:23 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
Now there is another possibility that you may be having. I recently  updated 
file _http://www.garlic.com/~lynn/2007e.html_ 
(http://www.garlic.com/~lynn/2007e.html) 
with  most recent posts. If your browser has a earlier version of...
 
You still have not gotten the point.  The problem I have is not with  my 
browser or any of your fine articles that you have posted.  My problem  is that 
you keep ignoring or missing my one and only question.  So here it  is again in 
slow motion:
 
If IBM had never invented the 2321, why would we  have ever needed the bb 
part of the bbcchh seek  address?
 
Please do not answer this question by pointing me to urls.  Please  summarize 
the answer in a very few words.
 
Bill  Fairchild
Plainfield, IL

Criticism and dissent are the indispensable  antidote to major delusions. 
[Alan Barth, 1951; The Loyalty of Free  Men]


BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

[EMAIL PROTECTED] wrote:
 You still have not gotten the point.  The problem I have is not with  my 
 browser or any of your fine articles that you have posted.  My problem  is 
 that 
 you keep ignoring or missing my one and only question.  So here it  is again 
 in 
 slow motion:
  
 If IBM had never invented the 2321, why would we  have ever needed the bb 
 part of the bbcchh seek  address?
  
 Please do not answer this question by pointing me to urls.  Please  summarize 
 the answer in a very few words.

reference posts:
http://www.garlic.com/~lynn/2007e.html#64 FBA rant 
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#2 FBA rant

i don't know. as implied in this post ... where i raised the question
about a number of code names
http://www.garlic.com/~lynn/2007e.html#38 FBA rant

including 2321 ... somebody then posted an answer providing what they thot to
have been the 2321 original project code name. that answer as to the 2321
code name then appeared to initiate some additional topic drift with respect
to 2321.

I then subsequently posted that the univ. where i was undergraduate had
obtained a 2321 as part of an ONR library automation grant and needed to
make sure it ran with both CICS and cp67
http://www.garlic.com/~lynn/2007e.html#51 FBA rant

I also happened to mention here 
http://www.garlic.com/~lynn/2007e.html#63 FBA rant

that i happened to run into an engineer many years later that claimed
to have been part of the original 2321 development team.

i apologize that i've not done what you have instructed me to do. 
maybe you should also try ordering some number of other people to also 
answer your questions.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

Anne  Lynn Wheeler [EMAIL PROTECTED] writes:
 i apologize that i've not done what you have instructed me to do.
 maybe you should also try ordering some number of other people to also
 answer your questions.

reference:
http://www.garlic.com/~lynn/2007f.html#3 FBA rant

part of the reason that i don't really know the definitive answer to
your question is that BB in BBCCHH may have been planned for a number
of related products ... besides the 2321.  i have some vague
recollection of discussions related to 1360/pdss which may have also
motivated the inclusion of BB in 360 ckd dasd architecture; i.e. even
if 2321 hadn't shipped ... the decision to include BB may have been
made assuming a variety of products that might use it.

in this 1360/PDSS reference
http://en.wikipedia.org/wiki/IBM_1360

it mentions having a total capacity of 2,250 cells possibly helping
motivate two digit BB field (as opposed to ten 2321 cells) under some
assumption that such devices might also eventually appear attached to
360 channels.

this may have also contributed to the DASD acronym for direct access
storage device ... because of the variety of storage technologies that
were being used in the period (not just disk and not just magnetic).

the above article implies that 1360 saw limited deployment, in part
because of various follow-on magnetic related storage devices like
3850 (however, it doesn't mean that the senior engineers hadn't
originally anticipating that such devices might be attached to 360
channels).

3850 reference
http://en.wikipedia.org/wiki/IBM_3850

there is mention in the above that the tape cartridges originally were
to be directly addressed ... possibly also using BB specification
... but it was eventually changed to the virtualized 3330
implementation. So there is possibility that 3850 originally was
envisioned as (also) being much more of a 2321 kind of operation
(having up to 4720 cartridges ... possibly also fitting into the BB
specification).

past posts in this thread mentioning 2321:
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#51 FBA rant
http://www.garlic.com/~lynn/2007e.html#63 FBA rant
http://www.garlic.com/~lynn/2007e.html#64 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant

part of the issue is all of the senior people that would have likely
been involved in thinking about justification for including BB as
part of the standard architecture were gone by the time i showed
up. the senior people having moved on was also the excuse given for
periodically calling me in to play disk engineer ... recent posts
mentioning periodically getting called in to play disk engineer:
http://www.garlic.com/~lynn/2007b.html#28 What is command reject
trying to tell me?
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007e.html#63 FBA rant

lots of past posts mentioning getting to play around in dasd
engineering lab (bldg 14) and dasd product test lab (bldg 15)
... sort of across the street from sjr in bldg. 28.
http://www.garlic.com/~lynn/subtopic.html#disk

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-07 Thread Shmuel Metz (Seymour J.)

In [EMAIL PROTECTED], on 03/03/2007
   at 01:16 PM, Anne  Lynn Wheeler [EMAIL PROTECTED] said:

speed matching attempted to retrofit 3880/3380 to 168 and 303x
machines with channel running at 1.5mbyte max

Not quite; the 370/168 had two type of block multiplexor channel,
single byte and 2 byte. The 2 byte channel ran at 3 MB/s. The 3880
only supported the single byte channel, which was less expensive.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-07 Thread Shmuel (Seymour J.) Metz

In [EMAIL PROTECTED], on 03/03/2007
   at 08:27 AM, Shane [EMAIL PROTECTED] said:

And yep, we'd probably all like FBA support to have been taken up.

I asked for it three decades ago. I thought that it was a no brainer,
but IBM didn't agree.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-07 Thread Shmuel Metz (Seymour J.)

In [EMAIL PROTECTED], on 03/05/2007
   at 10:47 AM, Andreas F. Geissbuehler [EMAIL PROTECTED] said:

The venerable IBM 2321 A.K.A the strip picker,

ITYM noodle picker.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-07 Thread Anne Lynn Wheeler


Shmuel Metz , Seymour J. wrote:

Not quite; the 370/168 had two type of block multiplexor channel,
single byte and 2 byte. The 2 byte channel ran at 3 MB/s. The 3880
only supported the single byte channel, which was less expensive.


re:
http://www.garlic.com/~lynn/2007e.html#40 FBA rant

about the only thing that i remember that would use the 2byte/3mbyte/sec 
channel was the 2505-1 fixed head disk.
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html

2505-2 was 1.5mbyte/sec, 11.2mbyte capacity, 5millsecond avg. rotational delay

2505-1 was 3mbyte/sec and 5.4mbyte capacity ... heads were positioned i.e. so 
the
avg. rotational was cut in half from 5milliseconds to 2.5millseconds, data 
transfer
rate doubled from 1.5mbytes/sec to 3mbyte/sec, and data capacity cut in half 
from
11.2mbyte to 5.4mbyte.

I never actually knew of customer with either 2305-1 and/or 3mbyte/sec (2byte) 
channel

Nominally bustag cable channel was rated at 200ft max. distance ... but even 2505-2 (at 
1.5mbyte/sec) could present problems. We had 370/158 that had troubles with (2305-2 controller) 
2835 down around 50ft that was fixed by configuration with shorter cable.


Data streaming (reduce the requirement end-to-end synch on every byte) allowed 
for both
higher data rate as well as doubling maximum channel cable distances.

Slightly related from long ago and far away ... effectively native mode
for electronic paging disk is very close to FBA kind of operation (w/o
the rotational delay)

From: wheeler
Date: 08/05/82  16:17:32

re: 1655 electronic disks; Native mode operation has the same
performance as 2305 simulation ... not faster, no slower.

However, in native mode all 12meg worth of drum is used as data
blocks. In 2305 simulation mode, only that amount of formated space is
used for data blocks. VM uses a format which only utilizes approx.
9.5meg worth of data blocks (the rest is inter-record gaps and dummy
block spacers to optimize slot sorting). The result is native mode
represents about a 30% increase in drum space (an 1655 box with 4
simulated 2305s becomes the equivalent of 5.3 2305s in native mode).

They have been saying they would have a 3meg. data streaming option
available by August for 1655. That would mean twice the data transfer
rate compared to either a real 2305 or an 1655 simulated 2305. I
haven't confirmed it, but it was my understanding that 3meg. data
streaming would be available for either 2305 or native mode.

SJRLVM1, SJEVM5, and at least one machine in STL are running 1655s (48
meg./4 drum) in 2305 mode. They are all 1.5meg. versions. In addition,
SJRLVM1 has a data streaming STC 2-drum electronic device (3
megabytes) ...  the STC drums don't have a native mode option. We
also have a combination of real 2305s and 3380s and are in the process
of running various performance comparisons.

Note: at 1.5meg. mode, an electronic drum has the same maximum
thru-put capacity as a 2305 drum ... under VM at maximum load, there
are long CCW chains transfering multiple page requests in one SIO
operation. The data transfer is the same, so the electronic drums
don't buy anything there. It is in the area of average access time
that electronic drums improve performance. A 2305 drum has a 5
milliscond avg. rotational delay (access delay) per SIO. An electronic
drum has avg access delay of 300-400 microseconds (approx. 1/20th of a
2305). Time to transfer one page is approx. 2.7 milliseconds for
either devices at 1.5meg. transfer. For long CCWS chains with one
rotational delay per 20-30 pages transfered performance is about the
same:

 chain2305 [EMAIL PROTECTED]  [EMAIL PROTECTED]
 sizeelapsed   elapsed elapsed

1 page7.7mills3.0mills1.6mills
2 page   10.4mills5.7mills2.9mills
5 page   18.5mills   13.9mills 7 mills
10 page   32  mills   27.4mills   13.9mills
20 page   58  mills   54.4mills   27.4mills

On a moderately loaded, page bound system, electronic drums can
significantly improve the paging performance.

... snip ...

above comment about moderately loaded, page bound system ... i.e.  w/o
long page CCW chains so real rotational delay was significant part of
service time per page transfer.

As part of my resource manager shipped in the mid-70s ... I had also
shipped page migration support (pages that became inactive on
higher speed devices would be migrated to lower speed devices)
... improving effectiveness of higher speed devices for paging 
operation.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-07 Thread Anne Lynn Wheeler


Anne  Lynn Wheeler wrote:

As part of my resource manager shipped in the mid-70s ... I had also
shipped page migration support (pages that became inactive on
higher speed devices would be migrated to lower speed devices)
 improving effectiveness of higher speed devices for paging operation.


re:
http://www.garlic.com/~lynn/2007e.html#59 FBA rant

for further drift ...  with regard to resource manager and various
strategies supporting paging devices ... 

various resource manager posts here ... I had originally done dynamic 
adaptive resource manager for cp67 as an undergraduate in the 60s. it 
was frequently referred to as fair share scheduler because the default 
resource policy was fair share.

http://www.garlic.com/~lynn/subtopic.html#fairshare

Most of the resource manager implementation had been dropped in the morph 
from cp67 to vm370, but i then got an opportunity to reintroduce it as 
independent resource manager product. The resource manager also got selected to be 
the guinee pig for kernel priced software (which had still been free up until then) ...

misc. posts mentioning evolution of unbundling and charging for software
http://www.garlic.com/~lynn/subtopic.html#unbundle

not too long after I shipped the resource manager ... is when I really started
noticing significant shift in both processor speeds and real storage
sizes vis-a-vis conventional disk technology. One of the issues was real
storage sizes was starting to rival or exceed the sizes of conventional
high-speed paging devices. It was then when I first implemented
dynamic adaptive switching between duplicate and no-duplicate
strategies ... discussed in this post in conjunction with IRONWOOD (3880-11
controller disk cache)
http://www.garlic.com/~lynn/2007e.html#42 FBA rant

but I originally implemented for 2305 fixed-head paging drums. 
Duplicate/no-duplicate
support didn't ship to customers, but saw some pretty wide deployment 
internally.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-05 Thread Andreas F. Geissbuehler

The venerable IBM 2321 A.K.A the strip picker, the one responsible for 
the mbb in mbbcchhr -- did CP/67 or VM ever support the 2321 ?

Andreas F. Geissbuehler
AFG Consultants Inc.
http://www.afgc-inc.com/

On Sun, 4 Mar 2007 10:25:47 +0100, Birger Heede [EMAIL PROTECTED] wrote:

The 2321 was the Mars File according to IBM archives

Birger Heede
IBM Denmark

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-05 Thread Anne Lynn Wheeler


Andreas F. Geissbuehler wrote:
The venerable IBM 2321 A.K.A the strip picker, the one responsible for 
the mbb in mbbcchhr -- did CP/67 or VM ever support the 2321 ?


at the univ. where i was undergraduate ... and doing a lot of enhancements to
MFT and then MVT (lot of it associated with getting typically univ. workload 
running
three times faster than what you would get with a vanilla os360 sysgen) ... 

then the univ. was selected to be first early install for cp67 ... three people 
from the science center 
http://www.garlic.com/~lynn/subtopic.html#545tech


coming out the last week of jan68 to install cp67. I then got to do a lot of
performance enhancements to cp67 ... especially running MFT and then MVT in 
virtual
machine ... as well as fixing any bugs in cp67 related to running os/360
in virtual machine. As before some posts mentioning a presentation that
I gave at aug68 share meeting in boston on some work on os/360 performance
enhancements, cp67 performance enhancements and enhancements running os/360
in virtual machines
http://www.garlic.com/~lynn/94.html#18 CP/67  OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67  OS MFT14

now one of the other things, was the univ. was also selected to be one of the original 
beta-test sites for the first cics product release. it was being used for project that
univ had related to an ONR grant to the univ library for library automation. recent post 
mentioning having to do shoot some CICS bugs as part of that effort (original CICS

had been developed at a customer account and appeared to have used a specific 
set
of BDAM options, library automation project was using a different set of BDAM 
options
and some of the bugs were related to CICS dataset OPEN with other than the 
originally
used BDAM options) 
http://www.garlic.com/~lynn/2007e.html#37 Quote from comp.object


part of the library automation project was a 2321 datacell ... so i had to make
sure it ran with mvt/cics/bdam ... as well as running under cp67.

lots of past posts happening to mention (early) cics /or bdam
http://www.garlic.com/~lynn/subtopic.html#bdam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-05 Thread Gregory, Gary G

The first versions of the 3090 service processor did use the 3370's for
microcode and 4331's in the service processor.  The later versions - I
think starting with the J model had replaced the 4331 with 4361's.
Back in about 1987 IBM had big marketing campaign offering large
discounts to shops running 4361 processors; they were trying to get us
to upgrade to 4381's.  

Back then a friend of mine in NY told me they needed the 4361 gates for
the 3090 production line. 

Gary Garland Gregory, MS
CA 
Senior Software Engineer
Tel: +1-214-473-1863
Fax: +1-214-473-1050
[EMAIL PROTECTED]





-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Anne  Lynn Wheeler
Sent: Saturday, March 03, 2007 10:54 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: FBA rant

[EMAIL PROTECTED] wrote:
 Not enough caffeine...should be VM/XA

vm370 (and CMS) shipped with 3310 and 3370 support when the devices
first became available in the 70s.

3310/piccolo was used by the 3081 service process (running custom
programming on microprocessor) ... including paging device for 3081
paged microcode ... old post discussing SIE instruction implementation
trade-offs between 3081 and 3090 (including 3081 would be paging part
of the
microcode)
http://www.garlic.com/~lynn/2006j.html#27 virtual memory

I don't remember for sure whether FBA (3370) was used by the 3090
service processor or not.
The 3090 service processor started out being a highly customized version
of vm370 release 6 running on 4331 processor . Before FCS, 3090 service
processor was upgraded to high customized version of vm370 release 6
running on a pair of 4361 processors (with service processor menu
screens implemented in CMS's IOS3270).

previous posts
http://www.garlic.com/~lynn/2007e.html#35 FBA rant
http://www.garlic.com/~lynn/2007e.html#38 FBA rant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-05 Thread Gregory, Gary G

Also, the FTA (File Tape Adapter) on the 4331/4361's would allow you to
attach the 3310/3370's directly to the processor without having to have
a 3880.  We eventually had to get the DASD controller when we upgraded
to the 4381.

Gary Garland Gregory, MS
CA 
Senior Software Engineer
Tel: +1-214-473-1863
Fax: +1-214-473-1050
[EMAIL PROTECTED]





-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ed Finnell
Sent: Saturday, March 03, 2007 11:49 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: FBA rant

 
In a message dated 3/3/2007 10:44:04 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

that  should be 3310  3370s ... 3330, 3340, 3350 were all ckd. 3340s
were  
removable packs that were totally enclosed including the arm access
mechanism.  
There was 3375 which basically was (hardware) emulation of CKD on 3370  
device.





Yeah, we had both on a 4361. I don't remember all the details since it
was  
under the purview of the VM group. Think they went out of their way to
avoid  
3330's and 3350's. One of the very sharp MVSer's dad worked at Santa
Teresa and 
 we usually got excellent support for all geometries. The one exception
was 
the  3380 w/ speed matching buffer. The JES3 folks just wouldn't admit
that it  
existed or even take it into account. So we'd ZAP in support only to
find  it
SUP'd with next batch of PTFs. 
BRBRBR**BR AOL now offers
free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-05 Thread Robert A. Rosenberg


At 10:47 -0600 on 03/05/2007, Andreas F. Geissbuehler wrote about Re: FBA rant:


The venerable IBM 2321 A.K.A the strip picker, the one responsible for
the mbb in mbbcchhr


As well as having it media used as the ribbons for the SHARE Paddle Project.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-05 Thread Rick Fochtman

IIRC, CP/67 - CMS supported the Noodle Picker, but not as a Pseudo-FBA 
device.



Andreas F. Geissbuehler wrote:

The venerable IBM 2321 A.K.A the strip picker, the one responsible for 
the mbb in mbbcchhr -- did CP/67 or VM ever support the 2321 ?


Andreas F. Geissbuehler
AFG Consultants Inc.
http://www.afgc-inc.com/

On Sun, 4 Mar 2007 10:25:47 +0100, Birger Heede [EMAIL PROTECTED] wrote:

 


The 2321 was the Mars File according to IBM archives

Birger Heede
IBM Denmark
   



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

 




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-04 Thread Birger Heede


The 2321 was the Mars File according to IBM archives

Birger Heede
IBM Denmark


Anne  Lynn Wheeler wrote:

[EMAIL PROTECTED] wrote:

Likewise for VM/ESA 3340's, 3370's.


that should be 3310  3370s ... 3330, 3340, 3350 were all ckd. 3340s 
were removable packs that were totally enclosed including the arm access 
mechanism. There was 3375 which basically was (hardware) emulation of 
CKD on 3370 device.


part of the issue was that cp  cms ... always treated disks as logical 
FBA ... even going back to cp40 and cp67 implementations in the mid60s 
on 2311 and 2314 (ckd) ... and didn't really leverage any ckd features.


the one possible exception was internal modification originally done for 
the HONE system. HONE was the world-wide vm370 (originally cp67) based 
online service for marketing, sales, and field people. In the mid-70s 
the various US HONE datacenters were consolidated in northern cal (and 
the US HONE system started being cloned in more and more places around 
the world). I provided highly customized kernel for HONE operations for 
period of 15yrs or so (and some of my first trips outside the US was 
personally installing HONE clones in other parts of the world ... first 
one was when EMEA hdqtrs moved from US to Paris). misc. past posts 
mentioning hone

http://www.garlic.com/~lynn/subtopic.html#hone

the consolidation of some of the HONE vm370 datacenters provided 
opportunity for development of vm370 single-system-image support with 
front-end load-balancing and availability infrastructure directing 
branch office logon to specific processor. The mechanism utilized a 
special CKD sequence that performed a logical compareswap channel 
program to correctly syncronize logins across all processors in the 
complex. The compareswap channel program had originally been 
developed by the people at the Uithorn HONE system in Europe ... for 
coordinating logins across all processors in loosely-coupled complex. I 
believe that JES2 multi-access spool then started using a similar 
logical compareswap channel program for its loosely-coupled 
operation. This was to avoid the heavy penalty and overhead of doing 
full device reserve/release sequence.


Later the US hone complex was replicated first in Dallas and then a 3rd 
in Boulder (and could
provide geographic availability to US branch offices logins across all 
three datacenters).


for other drift ... recent post 
http://www.garlic.com/~lynn/2007e.html#16 Attractive Alternatives to 
Mainframes

mentioning coining disaster survivability and geographic survivability
http://www.garlic.com/~lynn/subtopic.html#available
when we were doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

For completely other topic drift ... the 370 compareswap instruction 
was originally invented by charlie at the science center

http://www.garlic.com/~lynn/subtopic.html#545tech

as part of his work on fine-grain multiprocessing locking for cp67 
kernel (precusor to vm370 developed at the science center). CAS was 
then chosen for the instruction ... because they are charlie's initials 
... and then had to come up with instruction name to go along with his 
initials. a couple recent posts on effort to get compareswap 
instruction into 370 architecture.


Then I also started doing a highly customized kernel for the disk 
development and product test labs

http://www.garlic.com/~lynn/subtopic.html#disk

related previous posts
http://www.garlic.com/~lynn/2007d.html#48 IBM S/360 series operating 
systems history
http://www.garlic.com/~lynn/2007d.html#51 IBM S/360 series operating 
systems history

http://www.garlic.com/~lynn/2007d.html#52 CMS (PC Operating Systems)
http://www.garlic.com/~lynn/2007d.html#65 IBM S/360 series operating 
systems history
http://www.garlic.com/~lynn/2007d.html#69 IBM S/360 series operating 
systems history
http://www.garlic.com/~lynn/2007d.html#72 IBM S/360 series operating 
systems history
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating 
systems history

http://www.garlic.com/~lynn/2007e.html#32 I/O in Emulated Mainframes
http://www.garlic.com/~lynn/2007e.html#33 IBM S/360 series operating 
systems history

http://www.garlic.com/~lynn/2007e.html#35 FBA rant

for other topic drift:
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was 
Re: Yamhill

http://www.garlic.com/~lynn/2005t.html#50 non ECC
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are 
worse than disks ?

http://www.garlic.com/~lynn/2006v.html#31 MB to Cyl Conversion

I'm trying to fill in rest of these code-names:
  2301   fixed-head/track (2303 but 4 r/w heads at time)
  2303   fixed-head/track r/w 1-head (1/4th rate of 2301)
Corinth2305-1 fixed

Re: FBA rant

2007-03-04 Thread Paul Gilmartin

In a recent note, Bruce Black said:

 Date: Sat, 3 Mar 2007 20:40:42 -0500
 
 My memory on DOS/VS is vague, but I believe they had VTOCs that were
 similar to CKD VTOCs but structured to fit in 512 sectors and to
 describe datasets in sectors.  To do something similar in z/OS would
 require that EVERY program which reads VTOC data, IBM, ISV, shareware,
 freeware and home-grown, would have to change to handle this format.
 This would be a major task, and is probably why IBM is reluctant to
 support them.
 
Even as PDSE support emulates the 256-byte PDS directories for
applications that read them directly, might the VTOC be similarly
emulated.

HFS can provide a model for the data emulation.  Today an HFS file
may be allocated and read or written with {B|Q}SAM.  There are two
modes: FILEDATA(BINARY) which provides excellent emulation of
RECFM(F[B]) -- it works for SYSIN, SYSLIN, and SYSLIB for most
utilities, and FILEDATA(TEXT) which emulates either RECFM(F[B]) or
RECFM(V[B]) with some restrictions.  I'd like to see a third mode,
FILEDATA(BDW), to store the RDW/BDW images in the HFS, permitting
faithful emulation of RECFM(V[B][S]).  This would immediately
allow an optimization of SMP/E which now receives an ORDER into
HFS and must transform it to Classic CKD for processing by
IEBCOPY.  That step could be eliminated if the transformation
were provided by the access method so IEBCOPY could read the
HFS directly.

but current HFS and PDSE interfaces to {B|Q}SAM provide a model
for access method support of FBA.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-04 Thread Anne Lynn Wheeler


Steve Myers wrote:

The problem is EXCP access to the VTOC.  There are a lot of programs 
that do that.



so there is a conversion period with some trailing support for old
disks for extended period of time ... which would have been pretty
much over if started in back in the early 80s.

also, could provide software simulation for CKD channel programs that
refuse to die ... basically as side-effect of virtual-to-real channel
program translation ... by whatever descendent of CP67's CCWTRANS
currently running in MVS. recent posts about initial mvt-VS2 converstion
was done by hacking CP67's CCWTRANS into the side of the MVT kernel
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems 
history

For virtual machine support, CP67's CCWTRANS had to copy the virtual
machine's channel program to a shadow channel program that reference
real addresses.  The same thing applies to channel programs from the
applications virtual address space (that is loaded with virtual
addresses) that need a real version of the original (virtual) channel
program created for real execution.

While the original CP67 CCWTRANS somewhat did (nearly) a one-for-one
conversion of each virtual CCW to a shadow/real CCW ... there were
various enhancements over the years (by both internal accounts and
customer accounts) that implemented full software simulation for
special/custom devices. Such implementations could be similarly moved
into the MVS kernel in a manner similarly to the way that CP67's
CCWTRANS was initially moved into VS2.

The strict exception to the above are any system applications that
run channel programs in virtual equal real where the requirement
for translation  shadow channel programs are eliminated ... however,
these should be a much smaller enumerated set of applications 
that would be in need of converstion.


Another example of such body of work is the various emulators that
allow current generation 360-genre operating systems and various other
processor architectures ... like intel and other machines. These
include similar capability to the original CP67 channel program
translation ... and I believe most of them also implement CKD
emulation on fixed-block real devices. In manner similar to migration
of CP67's CCWTRAN channel program translator into VS2 kernel
... perform somewhat analogous migration of various software CKD
channel program emulation into the MVS kernel.

The other body of code providing similar function is all the hardware
controller functions emulating CKD operations on devices that are
really fixed-block architecture of one form or another. Provide
some flavor of this as part of conversion transition.

one of my early contentions that it would have been much simpler and
easier and have much longer term benefits than the iteration
involving adding support for ECKD. The need for any of the ECKD-type
stuff would have mostly evaporated in transition of CKD to fixed-block
architecture environment

post posts in this and related thread:
http://www.garlic.com/~lynn/2007d.html#48 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007d.html#51 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007d.html#65 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007d.html#69 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007d.html#72 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007e.html#33 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007e.html#35 FBA rant
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#39 FBA rant
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007e.html#42 FBA rant
http://www.garlic.com/~lynn/2007e.html#43 FBA rant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-03 Thread Charles Mills

Seems to me like a simpler bit of magic than that which makes PDSEs seem to
have 256-byte directory blocks.

For all of the LE programs, no problem.

For all of the assembler programs doing vanilla GETs and PUTs, no problem.

If you're manipulating BBCCHHRs, well, you're on your own. Similar to
programs that were parsing and manipulating the internals of NOTE words
before PDSE support.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Shane
Sent: Friday, March 02, 2007 8:40 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: FBA rant

Introducing a new DASD architecture should be a doddle. New playing
field - the old world doesn't even need to know it exists.

If they can slip media manager code in under the covers, why can't
they also add new functionality just for FBA.
Be nice if it is freely (and widely) documented though.

So the problem is ???.  ROI for all that time and effort.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
In a message dated 3/3/2007 12:04:52 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

There  were FBA Drives under DOS/VS. They were transparent to the 
user/programs.  If it could be done then, why not now?




Likewise for VM/ESA 3340's, 3370's.
BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
In a message dated 3/3/2007 9:58:40 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Likewise  for VM/ESA 3340's, 3370's.




Not enough caffeine...should be VM/XA
BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

[EMAIL PROTECTED] wrote:

Likewise for VM/ESA 3340's, 3370's.

that should be 3310 3370s ... 3330, 3340, 3350 were all ckd. 3340s were
removable packs that were totally enclosed including the arm access mechanism.
There was 3375 which basically was (hardware) emulation of CKD on 3370 device.

part of the issue was that cp cms ... always treated disks as logical FBA ...
even going back to cp40 and cp67 implementations in the mid60s on 2311 and 2314
(ckd) ... and didn't really leverage any ckd features.

the one possible exception was internal modification originally done for the
HONE system. HONE was the world-wide vm370 (originally cp67) based online
service for marketing, sales, and field people. In the mid-70s the various US
HONE datacenters were consolidated in northern cal (and the US HONE system
started being cloned in more and more places around the world). I provided
highly customized kernel for HONE operations for period of 15yrs or so (and
some of my first trips outside the US was personally installing HONE clones in
other parts of the world ... first one was when EMEA hdqtrs moved from US to
Paris). misc. past posts mentioning hone
http://www.garlic.com/~lynn/subtopic.html#hone

the consolidation of some of the HONE vm370 datacenters provided opportunity for development of vm370
single-system-image support with front-end load-balancing and availability infrastructure directing branch office logon
to specific processor. The mechanism utilized a special CKD sequence that performed a logical compareswap channel
program to correctly syncronize logins across all processors in the complex. The compareswap channel program had
originally been developed by the people at the Uithorn HONE system in Europe ... for coordinating logins across all processors in
loosely-coupled complex. I believe that JES2 multi-access spool then started using a similar logical compareswap
channel program for its loosely-coupled operation. This was to avoid the heavy penalty and overhead of doing full device
reserve/release sequence.

Later the US hone complex was replicated first in Dallas and then a 3rd in
Boulder (and could
provide geographic availability to US branch offices logins across all three
datacenters).

for other drift ... recent post
http://www.garlic.com/~lynn/2007e.html#16 Attractive Alternatives to Mainframes

mentioning coining disaster survivability and geographic survivability
http://www.garlic.com/~lynn/subtopic.html#available
when we were doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

For completely other topic drift ... the 370 compareswap instruction was
originally invented by charlie at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

as part of his work on fine-grain multiprocessing locking for cp67 kernel (precusor to vm370
developed at the science center). CAS was then chosen for the instruction ...
because they are charlie's initials ... and then had to come up with instruction name to go
along with his initials. a couple recent posts on effort to get compareswap instruction
into 370 architecture.

Then I also started doing a highly customized kernel for the disk development
and product test labs
http://www.garlic.com/~lynn/subtopic.html#disk

related previous posts
http://www.garlic.com/~lynn/2007d.html#48 IBM S/360 series operating systems
history
http://www.garlic.com/~lynn/2007d.html#51 IBM S/360 series operating systems
history
http://www.garlic.com/~lynn/2007d.html#52 CMS (PC Operating Systems)
http://www.garlic.com/~lynn/2007d.html#65 IBM S/360 series operating systems
history
http://www.garlic.com/~lynn/2007d.html#69 IBM S/360 series operating systems
history
http://www.garlic.com/~lynn/2007d.html#72 IBM S/360 series operating systems
history
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems
history
http://www.garlic.com/~lynn/2007e.html#32 I/O in Emulated Mainframes
http://www.garlic.com/~lynn/2007e.html#33 IBM S/360 series operating systems
history
http://www.garlic.com/~lynn/2007e.html#35 FBA rant

for other topic drift:
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re:
Yamhill
http://www.garlic.com/~lynn/2005t.html#50 non ECC
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than
disks ?
http://www.garlic.com/~lynn/2006v.html#31 MB to Cyl Conversion

I'm trying to fill in rest of these code-names:
2301 fixed-head/track (2303 but 4 r/w heads at time)
2303 fixed-head/track r/w 1-head (1/4th rate of 2301)
Corinth2305-1 fixed-head/track
Zeus 2305-2 fixed-head/track
2311
2314
2321 data-cell washing machine

Re: FBA rant


[EMAIL PROTECTED] wrote:

Not enough caffeine...should be VM/XA


vm370 (and CMS) shipped with 3310 and 3370 support when the devices first 
became available in the 70s.

3310/piccolo was used by the 3081 service process (running custom programming on microprocessor) ... 
including paging device for 3081 paged microcode ... old post discussing SIE 
instruction implementation trade-offs between 3081 and 3090 (including 3081 would be paging part 
of the
microcode)
http://www.garlic.com/~lynn/2006j.html#27 virtual memory

I don't remember for sure whether FBA (3370) was used by the 3090 service 
processor or not.
The 3090 service processor started out being a highly customized version of 
vm370 release 6 running on 4331 processor . Before FCS, 3090 service processor 
was upgraded to high customized version of vm370 release 6 running on a pair of 
4361 processors (with service processor menu screens implemented in CMS's 
IOS3270).

previous posts
http://www.garlic.com/~lynn/2007e.html#35 FBA rant
http://www.garlic.com/~lynn/2007e.html#38 FBA rant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
In a message dated 3/3/2007 10:44:04 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

that  should be 3310  3370s ... 3330, 3340, 3350 were all ckd. 3340s were  
removable packs that were totally enclosed including the arm access mechanism.  
There was 3375 which basically was (hardware) emulation of CKD on 3370  
device.





Yeah, we had both on a 4361. I don't remember all the details since it was  
under the purview of the VM group. Think they went out of their way to avoid  
3330's and 3350's. One of the very sharp MVSer's dad worked at Santa Teresa and 
 we usually got excellent support for all geometries. The one exception was 
the  3380 w/ speed matching buffer. The JES3 folks just wouldn't admit that it  
existed or even take it into account. So we'd ZAP in support only to find  it
SUP'd with next batch of PTFs. 
BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
In a message dated 3/3/2007 10:59:23 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

I don't  remember for sure whether FBA (3370) was used by the 3090 service 
processor or  not.
The 3090 service processor started out being a highly customized  version of 
vm370 release 6 running on 4331 processor . Before FCS, 3090  service 
processor was upgraded to high customized version of vm370 



Yeah, that's kinda foggy too. By the time we upgraded to 3090-400J(circa  
1989) the 9032(?)service processors were all  9370's.
BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-03 Thread Ed Gould


On Mar 3, 2007, at 9:57 AM, Ed Finnell wrote:



In a message dated 3/3/2007 12:04:52 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:

There  were FBA Drives under DOS/VS. They were transparent to the
user/programs.  If it could be done then, why not now?


Err semi transparent.. the dos jcl had to be changed.. and if I  
recall it wasn't fun. We had a test system that we ran on a 4331  
under VM and it was lets says interesting.


Ed








Likewise for VM/ESA 3340's, 3370's.
BRBRBR**BR AOL now  
offers free

email to everyone.  Find out more about what's free from AOL at
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-03 Thread Gerhard Postpischil


Anne  Lynn Wheeler wrote:
that should be 3310  3370s ... 3330, 3340, 3350 were all ckd. 3340s 
were removable packs that were totally enclosed including the arm access 
mechanism. There was 3375 which basically was (hardware) emulation of 
CKD on 3370 device.


I worked at a service bureau in the seventies that ran, in 
addition to a 360/65 (later two 165s), some Digital Equipment 
machines. I was fascinated to note that their DASD consisted of 
3330s, individually mounted, with build in controllers to make 
them behave like FBA drives. They were formatted to a fixed 
block size of 512, which wasted most of the capacity.


Gerhard Postpischil
Bradford, VT

new e-mail address: gerhardp (at) charter (dot) net

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant


[EMAIL PROTECTED] wrote:
Yeah, we had both on a 4361. I don't remember all the details since it was  
under the purview of the VM group. Think they went out of their way to avoid  
3330's and 3350's. One of the very sharp MVSer's dad worked at Santa Teresa and 
 we usually got excellent support for all geometries. The one exception was 
the  3380 w/ speed matching buffer. The JES3 folks just wouldn't admit that it  
existed or even take it into account. So we'd ZAP in support only to find  it
SUP'd with next batch of PTFs. 


whole e-ckd stuff somewhat came out of trying to get 3380 speed matching buffer 
stuff working.
3380/3880 introduced data streaming and 3mbyte channels raising the max channel 
distance (daisy-chain) from 200ft to 400ft. previously bustag had synchronous end-to-end 
handshake
on every byte transferred. data streaming relaxed that requirement ... 
doubling both the
typical max. data transfer from 1.5mbyte to 3mbyte and also max channel distance from 200ft to 
400ft. speed matching attempted to retrofit 3880/3380 to 168 and 303x machines with channel running at 1.5mbyte max (w/o 3mbyte data streaming support)


part of the FBA rant was the significant pain/cost of trying to get e-ckd  
speed matching working could have been totally eliminated by directly supporting 
FBA (at a drastically lower cost/effort).

lots of posts about doing operating system for disk development and product test labs (bldgs. 1415) was debugging 3880 and 3380 problems. 
http://www.garlic.com/~lynn/subtopic.html#disk


and in part because I was around trying to figure out what was going on to 
compensate for hardware incorrect/error operations in the software ... i would 
also periodically get pulled into playing hardware for the engineers. the 
excuse given roping me into playing hardware engineer was that so many of the 
senior engineers had departed (for one reason or another).

old posts mentioning the period:
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2003e.html#7 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003e.html#9 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2007b.html#28 What is command reject trying to 
tell me?
including this old email reference in the above post
http://www.garlic.com/~lynn/2007b.html#email800402

The previous post that started the FBA rant topic drift
http://www.garlic.com/~lynn/2007e.html#33 IBM S/360 series operating systems 
history

had email that had first paragraph on speed-matching buffer edited out
http://www.garlic.com/~lynn/email820907

From: wheeler
Date: 09/07/82  12:16:54

STL cannot even handle what they currently have. Calypso (3880 speed
matching buffer using ECKD) is currently in the field and not
working correctly. Several severity one situations. Engineers are on
site at some locations trying to solve some hardware problems ... but
they have commented that the software support for ECKD appears to be
in even worse shape ... didn't even look like it had been tested.

IBM double density (double the number of tracks) are here also. The
engineers have been fighting with the OS people (completely
unsuccessfully) to support the box in native mode .. i.e. one device
with twice the number of cylinders as a 3350. OS data management
people would have nothing of it. Several engineers who had MVT
experience said that they could go in and do it easily just by
defining a new device type and updating a couple of tables (almost as
trivial as what it takes for VM). OS data management replied that
things have completely changed since then, implying that they might
not even know all the routines that may have tables now. Result is
that the engineers have been forced into simulating two 3350 drives on
a single double density 3350 because the OS crowd is completely
incapable of getting their act together. As a result any performance
optimization techniques are going to be blown almost completely out of
the window (in some ways worse than effect of multi-track search). Not
only is two device simulation going to completely lay to waste any
ordered seek queueing algorithms (as bad as what happens in a multiple
CPU, shared DASD situation) ... but VM is stuck with the design also.

Based on the current record so far ... any investigation into MVS
support of FBA is going to be little more than another throw-away task
force report w/o any productive results.

... snip ...  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

 
In a message dated 3/3/2007 2:31:29 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

on every  byte transferred. data streaming relaxed that requirement ... 
doubling both  the
typical max. data transfer from 1.5mbyte to 3mbyte and also max channel  
distance from 200ft to 
400ft. speed matching attempted to retrofit  3880/3380 to 168 and 303x 
machines with channel running at 1.5mbyte max (w/o  3mbyte data streaming 
support)




Guess the next iteration was the 3380 D/E's and 3880-11's and 13's. Think  
the 11's made it to production but the 13's never did. Soon after(mid 80's)I  
left for greener pastures and walked into Amdahl hell with the 6880 ESP...and  
STK SSDs. Whew, I lived to tell about! 
BRBRBR**BR AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant


[EMAIL PROTECTED] wrote:
Guess the next iteration was the 3380 D/E's and 3880-11's and 13's. Think  
the 11's made it to production but the 13's never did. Soon after(mid 80's)I  
left for greener pastures and walked into Amdahl hell with the 6880 ESP...and  
STK SSDs. Whew, I lived to tell about! 


-11 and -13 were 8mbyte 3880 disk controller caches. -11/ironwood was 4kbyte 
record/page
cache and -13/sheriff was full-track cache ... code name table in previous post
http://www.garlic.com/~lynn/2007e.html#38 FBA rant

the -21/-23 later increased the -11/-23 8mbyte cache size to 32mbytes.

i got involved in some of the issues about how to optimize use of disk caches 
...
what they could and couldn't do. here is recent post discussing the -13/-23 
track
cache on how to interpret some of the original claims.
http://www.garlic.com/~lynn/2007e.html#10 A way to speed up level 1 caches

and a couple recent posts discussing/mentioning ironwood
http://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller 
chache
http://www.garlic.com/~lynn/2007c.html#12 Special characters in passwords was 
Re: RACF - Password rules

there is reference to duplicate and no duplicate strategies ... given the 
size of
8mbyte ironwood page cache ... it wasn't impossible that when using ironwood 
for
primarily paging activity ... that every page located in an ironwood cache (in 
typical
configurations) was also duplicated in real processor memory (i.e. the 
aggregate size
of processor real memories and typical aggregate ironwood caches were 
compareable).
Given that the page was in real memory ... there would be no reason that the 
duplicate
page in the ironwood cache would ever be used.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-03 Thread Ray Mullins

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell
 Sent: Saturday 03 March 2007 09:53
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: FBA rant

 In a message dated 3/3/2007 10:59:23 A.M. Central Standard Time,  
 [EMAIL PROTECTED] writes:

 I don't  remember for sure whether FBA (3370) was used by the 
 3090 service 
 processor or  not.
 The 3090 service processor started out being a highly 
 customized  version of 
 vm370 release 6 running on 4331 processor . Before FCS, 3090  service 
 processor was upgraded to high customized version of vm370 

 Yeah, that's kinda foggy too. By the time we upgraded to 
 3090-400J(circa  
 1989) the 9032(?)service processors were all  9370's.

I remember earlier 3090 models did have 3370's for the service processor;
this was 1987-1988 or thereabouts.

Our IBM FE said that the designers used it because someone said to use up
all the 3370s that weren't selling.  Not that I believed that 100%...

Later,
Ray

-- 
M. Ray Mullins 
Roseville, CA, USA 
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/ 
http://www.the-bus-stops-here.org/ 

German is essentially a form of assembly language consisting entirely of far
calls heavily accented with throaty guttural sounds. ---ilvi 
French is essentially German with messed-up pronunciation and spelling.
--Robert B Wilson
English is essentially French converted to 7-bit ASCII.  ---Christophe
Pierret [for Alain LaBonté]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant

2007-03-03 Thread Bruce Black

The 3370s supported by DOS/VS and VM, were FBA disks with a 512-byte 
sector size.


My memory on DOS/VS is vague, but I believe they had VTOCs that were 
similar to CKD VTOCs but structured to fit in 512 sectors and to 
describe datasets in sectors.  To do something similar in z/OS would 
require that EVERY program which reads VTOC data, IBM, ISV, shareware, 
freeware and home-grown, would have to change to handle this format.   
This would be a major task, and is probably why IBM is reluctant to 
support them.


My vague memory for VM is that when the disk was used directly by VM, no 
VTOC was involved.


However, FBA disks can be attached to z/Series today, via SCSI or FIBRE 
channels, but they are currently limited to Linux and VM systems.   I 
believe that IBM may allow access from z/OS in a future release.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant