V Series
Cathy Sullivan
Series and the Unisys V Series? Or point me to an internet reference? I do a
google and I get people's resumes and Unisys' web page on Year 2000.
Would lots of experience on the A Series translate OK to the V Series? Is
there any reference I could point a clueless recruiter or to?
Thanks.
Cathy
Dan Meyer
the A Series/ClearPath for many years and having been intimately involved
with the V Series to A Series migration software written 10 years ago.
Programming skills that translate:
COBOL (95%)
DMSII database (95%)
WFL (75%)
CANDE editor (60%)
Operations skills that translate:
All V Series peripherals were available on A Series hardware but the
operating system interfaces are different enough to drive a person crazy
V Series doesn't have many of the tools A Series operators take for
granted
Overall, an A Series operator working on a V Series will probably find
it frustrating
Dan Meyer
Unisys - Tredyffrin
"Cathy Sullivan" <cesul...@aol.comsf> wrote in message
news:20020304144056...@mb-fg.aol.com...
Edward Reid
> Can anybody out there tell me what the difference is between the Unisys A
> Series and the Unisys V Series?
They are totally different systems linked only by a common name for the
operating system and a few similar commands.
The B5000 was a Fortran machine. The A-Series is an Algol machine. The
V-Series was a COBOL machine. OK, so that oversimplifies nearly to the
point of falsehood, but there's a large grain of truth in it.
> Or point me to an internet reference?
Ha. Maybe there's something on the Unisys web site that says that the
V-Series is no longer produced, sold, or supported. But I doubt it.
Beyond that, I'd be surprised to find anything. Someone surely has some
manuals still, but only on paper -- the V-Series didn't make the
transition to electronic documentation.
> Would lots of experience on the A Series translate OK to the V Series?
Unlikely. It might be better than IBM experience, but not a whole lot
better. It also depends what sort of work they are talking about. If
it's for an actual running V-Series, someone here can probably guess
where it is with no further information ... that's how rare the
remaining operating ones are. If what they want is someone with
V-Series programming or operating experience to help a site that's now
on A-Series, there are quite a few people around who could help them,
but few of them are advertising the fact.
So I guess I'm saying that to answer the question, I'd have to know why
they are mentioning V-Series.
Edward Reid
Peter Kane
Cathy Sullivan wrote in message
<20020304144056...@mb-fg.aol.com>...
>Can anybody out there tell me what the difference is between the Unisys A
>Series and the Unisys V Series? Or point me to an internet reference? I
do a
>google and I get people's resumes and Unisys' web page on Year 2000.
>
>Would lots of experience on the A Series translate OK to the V Series? Is
The A Series experience would be useful, but only insofar as avoiding V
Series like the plague ;-)
Pete K
George Gray
initial software suite. The B5000 was also an ALGOL machine. The
ancestor of the V Series was the B3500 which Dave Dahm described as "a
machine that was designed with the explicit idea of being the target
of a COBOL compiler." Ref: Dave Dahm in B5000 Conference
Sid Hale
You have had a number of answers now, but I suspect that the variety of the
responses may have left you more confused than when you made the request. I
cut my teeth on the predecessor to the V-Series in 1971, and have worked on
all subsequent Unisys platforms (of the Burroughs gender) for the 30 years
since.
If your interest is in delivering end results to users (i.e. Application
Design/Development) then you will find Dan Meyer's response to be dead on.
From that viewpoint, almost all A-Series experience can be ported and used
effectively. If your interest is in OS/Hardware interface (i.e. internals)
then there is probably no better reference than Ed Reid.
Hope this helps.
Sid Hale
Chesapeake Software Services, Ltd.
"Cathy Sullivan" <cesul...@aol.comsf> wrote in message
news:20020304144056...@mb-fg.aol.com...
Edward Reid
> The B5000 was not a FORTRAN machine. FORTRAN was not part of the
> initial software suite. The B5000 was also an ALGOL machine.
My point was not what languages were implemented on the machines, but
what languages exhibited architectural models similar to the machines.
Whatever the designers were thinking of, whatever was actually
implemented, the B5000 could not address intermediate lex levels. This
made the architecture dissimilar from a truly block structured language
like Algol, and is borne out by the addressing restrictions placed on
Algol programs on the B5000. Of course, Algol was also implemented on a
variety of even more dissimilar machines -- similarity and
implementation are different matters.
The B5000 memory model *is* very close to the memory model for Fortran,
which until Fortran90 did not have nested subroutines and thus only
needed to address global and one local at any given time.
Edward Reid
Louis Krupp
> Whatever the designers were thinking of, whatever was actually
> implemented, the B5000 could not address intermediate lex levels. This
> made the architecture dissimilar from a truly block structured language
> like Algol, and is borne out by the addressing restrictions placed on
> Algol programs on the B5000. Of course, Algol was also implemented on a
> variety of even more dissimilar machines -- similarity and
> implementation are different matters.
I seem to recall a later B5500 ALGOL compiler that kludged the
intermediate lex level references and avoided the "NOT TRUE
GLOBAL" error (or whatever it was). This compiler was intended to
ease the transition to the B6000 series; I think it also used
B6000 bit numbering (47..0) instead of the (0..47) used on the
B5000.
I don't remember what the transitional ALGOL compiler was called --
Compatible ALGOL or something.
B5500 ALGOL without stream procedures was no fun.
Louis Krupp
J Ahlstrom
> On Mon, 4 Mar 2002 14:40:56 -0500, Cathy Sullivan wrote
> > Can anybody out there tell me what the difference is between the Unisys A
> > Series and the Unisys V Series?
>
> They are totally different systems linked only by a common name for the
> operating system and a few similar commands.
>
> The B5000 was a Fortran machine. The A-Series is an Algol machine. The
> V-Series was a COBOL machine. OK, so that oversimplifies nearly to the
> point of falsehood, but there's a large grain of truth in it.
>
The B5000 almost could NOT run fortran.
There was a Burroughs to Fortran source code translator
that did a lot but not all the translation needed.
Later - much later - there was a Fortran compiler.
Did it come from U of Wash?
JKA
--
If we want to not become {insert big behemoth company here}
maybe we should stop hiring our managers and VPs from there.
J Berringer
Bob Rahe
Louis Krupp <lkr...@NOSPAMPLEASE.pssw.com> wrote:
...
>I don't remember what the transitional ALGOL compiler was called --
>Compatible ALGOL or something.
XALGOL?
>B5500 ALGOL without stream procedures was no fun.
B5500 ALGOL WITH stream procedures was WAY scary!
--
----------------------------------------------------------------------------
|Bob Rahe, Delaware Tech&Comm Coll. / |
|Computer Center, Dover, Delaware / |
|Internet: b...@dtcc.edu (RWR50) / |
----------------------------------------------------------------------------
Chris Bremer
"Bob Rahe" <b...@hobbes.dtcc.edu> wrote in message
news:a632mh$fr5$1...@news.dtcc.edu...
> In article <3C84E3D4...@NOSPAMPLEASE.pssw.com>,
> Louis Krupp <lkr...@NOSPAMPLEASE.pssw.com> wrote:
> ...
>
> >I don't remember what the transitional ALGOL compiler was called --
> >Compatible ALGOL or something.
>
> XALGOL?
>
> >B5500 ALGOL without stream procedures was no fun.
>
> B5500 ALGOL WITH stream procedures was WAY scary!
Original B5000 ALGOL had stream procedures as Louie noted. Stream
procedures had little (no?) memory protection (remember B5500 did not have
tags). We used to have a little program called Hangit. It basically said
start here and replace by zero. Since we didn't tell it when to stop, it
just walked through memory putting zeros in all the bits till it hit
something important. As Bob said way scary.
The later B5000 ALGOL compiler was Extended ALGOL. It dropped stream
procedures in favor of the pointers we all know and love today.
Chris Bremer
Tom Herbertson
> In article <3C84E3D4...@NOSPAMPLEASE.pssw.com>,
> Louis Krupp <lkr...@NOSPAMPLEASE.pssw.com> wrote:
> ...
>
>
>>I don't remember what the transitional ALGOL compiler was called --
>>Compatible ALGOL or something.
>>
>
> XALGOL?
>
Again, to paraphrase Jim, you're both right. There were only 6 characters
to a file name node, and XALGOL (/DISK, I think) was used for the B 5500
Compatible Algol compiler. The B 6700 version was SYSTEM/XALGOL. The B
5500 language with stream procedures was called Extended Algol. There
also was a compiler with the file name of TSPOL, but I don't remember
what all the initials were for. I think the TS was for Time Sharing; one
of the MCPs you could use was the TSSMCP; the package included
CANDE/TSHARER. I think the other was called the Disk File MCP, and that
there was a predecessor that used a drum instead of a disk.
All this on a 32K word system (8 times as many characters, because of
48-bit words and 6 bits per BCL character): maybe a dozen interactive
users and a couple of compiles all at once.
--
Tom Herbertson
Unisys (Net2: 656 6427) Mail Stop 320, Mission Viejo CA 92691-2792 USA
Voice: +1 949 380 6427 mailto:tom.her...@unisys.com (office)
FAX: +1 949 380 6560 or mailto:herbe...@cox.net (home)
- My opinions are my own; I do not speak for Unisys or anyone else -
Tim McCaffrey
says...
is a stack based, 48 bit word (with additional tag bits) addressed (with
options to do byte addressing) descriptor based machine. This allows nested
procedures, libraries (DLLs), dynamic memory allocation to be easily
implemented.
The V series (aka Medium System) is decimal machine with digit (ie 4 bit)
addressing. Instructions are generally memory to memory (although there are
some index registers). Everything on the machine (seems) to be done in
decimal (even memory dumps come out with decimal addresses).
There was some parallel development between the systems, so that if you
know CANDE, DMSII, Cobol 85, it is pretty much the same between the two.
However, if the V series shop is using a CP3680 and SRI-EDIT, things might
be a little more difficult :).
The ODT commands were similar between the systems (although not exactly the
same), they used the same terminals (poll select or point-to-point protocol),
and had similar concepts and basically used the same acronyms to mean the
same thing.
They are enough different though that an A series person would probably
feel like they fell into the Bizzaro universe when using a V series.
- Tim
Bob Rahe
Chris Bremer <cbr...@dynamicsolutions.com> wrote:
>
>"Bob Rahe" <b...@hobbes.dtcc.edu> wrote in message
>news:a632mh$fr5$1...@news.dtcc.edu...
>> In article <3C84E3D4...@NOSPAMPLEASE.pssw.com>,
>> Louis Krupp <lkr...@NOSPAMPLEASE.pssw.com> wrote:
>> ...
>>
>> >I don't remember what the transitional ALGOL compiler was called --
>> >Compatible ALGOL or something.
>>
>> XALGOL?
>>
>> >B5500 ALGOL without stream procedures was no fun.
>>
>> B5500 ALGOL WITH stream procedures was WAY scary!
>
>Original B5000 ALGOL had stream procedures as Louie noted. Stream
>procedures had little (no?) memory protection (remember B5500 did not have
>tags). We used to have a little program called Hangit. It basically said
>start here and replace by zero. Since we didn't tell it when to stop, it
>just walked through memory putting zeros in all the bits till it hit
>something important. As Bob said way scary.
Well, the 5500 did have a tagged architecture but the tags were
different than the later systems like the 6500/6700 etc. I.e. they
weren't a separate group of bits. And they had memory protection based
on them. It was just that stream procedures could ignore them.
>The later B5000 ALGOL compiler was Extended ALGOL. It dropped stream
>procedures in favor of the pointers we all know and love today.
Edward Reid
> Well, the 5500 did have a tagged architecture but the tags were
> different than the later systems like the 6500/6700 etc. I.e. they
> weren't a separate group of bits. And they had memory protection based
> on them. It was just that stream procedures could ignore them.
The high order bit (0 on the B5500, 47 on the B6700) was the flag bit.
Off indicated an operand. The legacy of this is that bit 47 is still
unused for numeric operands on the current A/NX/LX systems. The format
of numeric operands (at least single precision) remains the same as it
was on the B5500. Presumably this was done to make conversion easier,
and perhaps even to aid in bidirectional data exchange. A lot of
progress in floating point design occurred between 1960 and 1970, and
it seems unlikely that they would have retained that funky floating
point format for any reason other than compatibility.
Edward Reid
Cathy Sullivan
<sid...@chspk.com> writes:
>If your interest is in delivering end results to users (i.e. Application
>Design/Development) then you will find Dan Meyer's response to be dead on.
>From that viewpoint, almost all A-Series experience can be ported and used
>effectively. If your interest is in OS/Hardware interface (i.e. internals)
>then there is probably no better reference than Ed Reid.
>
Thanks Sid,
You are right, the response by Dan is more helpful to me. And answered my
question, sort of!
I'm glad I was able to start a conversation.
Cathy
Mark Benedict
applies as well. I do notice that some handy V series commands which were
not previously available on A series have been implemented (e.g. FI and
A N = ) on A series.
Regards
Mark
Lee Bertagnolli
> Having had to go the other way round (V to A) the bizarro universe concept
> applies as well. I do notice that some handy V series commands which were
> not previously available on A series have been implemented (e.g. FI and
> A N = ) on A series.
How about BO DEREK IS A VERY SEXY LADY ?
That was my favorite V-series commands.
--Lee
George Gray
> There was a Burroughs to Fortran source code translator
> that did a lot but not all the translation needed.
> Later - much later - there was a Fortran compiler.
> Did it come from U of Wash?
>
>
> JKA
AS best I can make out from the B5000 Conference, the FORTRAN to ALGOL
translator was developed in 1965: two years after delivery of first
B5000.
Jim Haynes
Edward Reid <edw...@paleo.org> wrote:
>
>Whatever the designers were thinking of, whatever was actually
>implemented, the B5000 could not address intermediate lex levels. This
>made the architecture dissimilar from a truly block structured language
>like Algol, and is borne out by the addressing restrictions placed on
>Algol programs on the B5000. Of course, Algol was also implemented on a
>variety of even more dissimilar machines -- similarity and
>implementation are different matters.
>
>The B5000 memory model *is* very close to the memory model for Fortran,
>which until Fortran90 did not have nested subroutines and thus only
>needed to address global and one local at any given time.
>
pretty well frozen while ALGOL-60 was still being developed. There was,
I believe, a 1958 ALGOL that may have been closer to the way the B5500
turned out. And the people working on ALGOL had only FORTRAN as a
reference to a real, working language. You're right that the B5500 concepts
of a "main program level" and a "subroutine level" seem to come straight
from FORTRAN, and don't fit the multiple levels of nesting that ALGOL-60
allows.
Someone else mentioned the compatibility of floating point representation
between the B5500 and the B6500 and later machines. I was told by someone
who worked on the B6500 that management had dictated that the new machine
be completely compatible with the older one. That was unacceptable to the
designers, who could see all the things that just had to be changed, but
it did force them to keep the number representation the same.
The XALGOL compiler for the B5500 attempted to be compatible with B6500
ALGOL. This would allow B6500 buyers to start programming while they
still had a B5500. I didn't find that the nested procedure features
in XALGOL ever worked; at least they didn't for me. But I'm not a Real
programmer and maybe I was disobeying some restriction implicit in the
system.
ALGOL-60 turned out to be notoriously hard to write compilers for.
The B6500 architecture was strongly influenced by the Randell and Russell
book, "Algol 60 Implementation"
Randall Bart
awe as Lee Bertagnolli <l...@tyrol.bertagnolli.net> uttered:
>How about BO DEREK IS A VERY SEXY LADY ?
>That was my favorite V-series commands.
How about this currently valid CANDE command:
FILENAMESPLEASE D/= :SINGASONGOFSIXPENCE
I know someone who was burned by that kind of thing. He wrote his FORTRAN
programs such that they depended on the compiler to truncate names to six
characters, eg, he coded "CALL JANE FOR A GOOD TIME" but "SUBROUTINE JANE
FONDA". He went to a compiler with eight character names and discovered
this wasn't so smart.
--
RB |\ © Randall Bart
aa |/ ad...@RandallBart.spam.com Bart...@att.spam.net
nr |\ Please reply without spam 1-917-715-0831
dt ||\ Here I am: http://RandallBart.com/ I LOVE YOU
a |/ He Won't Get Far: http://www.callahanonline.com/calhat9.htm
l |\ DOT-HS-808-065 MSMSMSMSMSMSMS=6/28/107 Joel 3:9-10
l |/ Terrorism: http://www.markfiore.com/animation/adterror.html
Lee Bertagnolli
> 'Twas Thu, 7 Mar 2002 02:34:09 +0000 (UTC) when all comp.sys.unisys stood in
> awe as Lee Bertagnolli <l...@tyrol.bertagnolli.net> uttered:
>>How about BO DEREK IS A VERY SEXY LADY ?
>>That was my favorite V-series commands.
> How about this currently valid CANDE command:
> FILENAMESPLEASE D/= :SINGASONGOFSIXPENCE
> I know someone who was burned by that kind of thing. He wrote his FORTRAN
> programs such that they depended on the compiler to truncate names to six
> characters, eg, he coded "CALL JANE FOR A GOOD TIME" but "SUBROUTINE JANE
> FONDA". He went to a compiler with eight character names and discovered
> this wasn't so smart.
Wasn't there something to the SYSTEMSTATUS function call on the
large systems where if you queried device 69 and nothing was
attached, you would get a reply 'I AM NOT A PLEASURE UNIT'?
--Lee
Vern Farmer
fond of this platform......filenames had a max of 6 characters....(thats
'Nuff).....
The OS.... MCP.... support was de-commissioned in Oct 99.......
I think Citi bank in New Joisery is still using it and City of Columbus
OH......maybe some check sorters still out there....(Item Processing
System - IPS).....
In its hay day...late 70's to late 80's....small V's ...B-3500/V-340's ran
good size banks....using Thrift...software written by Burroughs.....and
bastardized by many users......Intrieve Corp in Cincy is running a subset of
that software on HP Unix and Oracle (I was the Project Leader on that
conversion).
I worked on the Global Financial System (GFS) for 10 years..with Unisys
...we supported both the A Series platform (now Clearpath NX) and V
Series....problem with V Series was the DMSII (database) access.......all DB
requests were funneled thru a single system router (read that as a
bottleneck) .....so all our users that came on board from high performance
flat file systems were forced to upgrade to much larger V5xx
systems...(marketeers loved the commissions).
So I would pursue the A series....Clearpath avenue.....although many of
those sites are dying out also.....lets hope the ES-7000 enjoys
popularity.......Vern
"Cathy Sullivan" <cesul...@aol.comsf> wrote in message
news:20020304144056...@mb-fg.aol.com...
Peter Ingham
IIRC, On the V Series the result descriptor obtained from reading a
non-existent device was "DEAD".
>--Lee
--
Peter Ingham
Lower Hutt
New Zealand
Edward Reid
> It's plausible, though I can't prove it, that the B5500 architecture was
> And the people working on ALGOL had only FORTRAN as a
> reference to a real, working language. You're right that the B5500 concepts
> of a "main program level" and a "subroutine level" seem to come straight
> from FORTRAN, and don't fit the multiple levels of nesting that ALGOL-60
> allows.
In pointing out that the B5000 architecture doesn't fit Algol very
well, I certainly don't mean to take anything away from the B5000
designers. The design was a real and major advance and still underlies
a lot of the A/NX/LX architecture, and the ideas had a lot of influence
outside Burroughs as well.
And indeed, programming language implementation was very poorly
understood at the time. A few gaps in the support, if anything, just
emphasize the many ways in which the architecture *did* support
programming languages.
Finally, of course, ALGOL-60 was not even designed as a language to be
implemented. It was a publication language, intended to be a lingua
franca for the exchange and publication of algorithms. It was indeed a
major advance in its intended domain, as there was at the time no
commonly understood notation for the purpose (and it was almost ten
years before Knuth's first book). As only one example, ALGOL-60 had no
I/O, something generally considered to be significant in computing. So
it isn't surprising that some things in ALGOL were hard to implement,
and in fact it is surprising that so much of it was, in the end, so
easy.
> The XALGOL compiler for the B5500 attempted to be compatible with B6500
> ALGOL. This would allow B6500 buyers to start programming while they
> still had a B5500. I didn't find that the nested procedure features
> in XALGOL ever worked; at least they didn't for me.
That's funny, since in retrospect, nested procedures aren't all that
important for programming. Yes, they are convenient and solve certain
problems very well, and going back to a flatter architecture would be
difficult. But as for features to implement on the B5500 to enable
early preparation for conversion to a B6700, nested procedures would
have been way down on my list. Standard Fortran didn't get nested
subroutines until 1990, and standard COBOL not until 1985.
> ALGOL-60 turned out to be notoriously hard to write compilers for.
Though only from the point of view of the time, when as I say,
programming language implementation was poorly understood.
Edward Reid
Cathy Sullivan
I am pursuing any Unisys related jobs that I can find. I have found that they
are few and far between. I would prefer working on the A-Series but I look at
whatever job announcements that mention Unisys A-Series. Actually, I do a
keyword search on Unisys and WFL because Unisys has such odd and non-unique
names for their platforms.
I am currently a bona fide Unisys sub-contractor here in lovely Richmond VA.
It has been two days and counting!
It would be great if I could get some experience with GPS. Short sighted
hiring managers want people with exact experience in it. Never mind that we
Unisys A-Series programmers aren't exactly numerous.
Cathy
In article <2jCi8.23989$WP2.5...@typhoon.atl.ipsvc.net>, "Vern Farmer"
Tom Herbertson
> Wasn't there something to the SYSTEMSTATUS function call on the
> large systems where if you queried device 69 and nothing was
> attached, you would get a reply 'I AM NOT A PLEASURE UNIT'?
I don't recall that one specifically, but I do know that prior to the
common symbolic, if you entered ")ON" or "*WK" (internally called ONAPL
and STARWK) at a B 7000 ODT (which was then still called the SPO, short
for Supervisory Print Out going back to the B 5500 which use an actual
printing Teletype device), you would get the response (to either, the
response was chosen "randomly") of "I AM NOT A PLEASURE UNIT" or "HANDS
OFF THE SPO". There actually was a ??WK which stood for Write Kore that
let you modify memory. (And its companion ??RK)