"Every Shop Has Some Assembler Somewhere" - course update

[Tune for subject line quote: "Everybody Loves Somebody Sometime"]

Well, it's true, every shop does have some Assembler code somewhere.

And I have just finished updating my Assembler course "z/OS
Assembler for applications Programmers" (3 days) to include
the new hardware instructions recently announced as well as
z/OS V1.5 and HLASM V1.5 changes.

While I promote our Assembler series as being for applications
programmers, systems programmers can often get a good running
start by attending some or all of these courses. Here is how
the curriculum is designed:

OS/390 Assembler Language: Classic (5 days) - the first
course for someone new to Assembler, includes all
the original S/360 instruction set plus S/370
and some later instructions

OS/390 Assembler Language: Interfaces (3 days) - the
natural follow on, covering static and dynamic
linkages, I/O macros, basic dump reading, and
some other commonly used macros (e.g.: WTO,
TIME, etc.)

OS/390 Assembler Language: Update (1 day) - for new
assembler programmers who have taken the above
sequence, and experienced Assembler programmers
who have not had a chance to learn the major
changes in the Assembler and hardware instructions
prior to z/Architecture

z/OS Assembler for Applications Programmers (3 days)
for new or experienced assembler programmers who
need to pick up the hardware and Assembler info
introduced by z/Archicture and z/OS.

The Assembler gurus in your shop are probably your sharpest
technical employees, and keeping them current pays back to
your bottom line in many ways (performance, debugging,
even morale and enthusiasm). If you are losing your
Assembler gurus to retirement, downsizing, outsourcing, etc.,
you should consider growing some replacements by a carefully
thought-out training program.

Go to our page about our Assembler curriculum:

http://www.trainersfriend.com/assemcurric.htm

there you will find more information, including links
to the detail information for each Assembler course we
offer (and, at the bottom of that page, links to courses
we teach that are mulit-lingual and include Assembler).

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716 - from anywhere
800-993-8716 - toll free from in the States

"S Comstock" <scomstock@aol.com> wrote in message
news:20040707143232.11581.00001180@mb-m11.aol.com...

> Well, it's true, every shop does have some Assembler code somewhere.

I think this statement might be a bit -- umm ... provincial.   It's true so
long as you summarily ignore any environment in which it's false, and there
are environments in which it is not only false today but has been false for
something over four decades.

I'd be hard-pressed to find any assembler code in your average Unisys MCP
shop.  There's none in the operating system, the support libraries, the
application support stuff (like the data base access routines), or the
compilers, and Unisys not only doesn't provide, but actively discourages the
third-party development of, assemblers for the system.

-Chuck Stevens

To clarify,  I think that Steve's course offering are intended ONLY for IBM
mainframe shops.  I know this post went (primarily) to such forums (fora?). 
 I
am not certain whether they are even particularly relevant in these days to 
VM
or VSE - even though the HLASM product *is* portable across such systems.

Much of what he offers for COBOL would *probably* be usable for other COBOL
environments, but (as far as I know) are certainly NOT tailored (targeted?) 
for
such.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:ccubh0$2t98$1@si05.rsvl.unisys.com...
>
> "S Comstock" <scomstock@aol.com> wrote in message
> news:20040707143232.11581.00001180@mb-m11.aol.com...
> 
>
> I think this statement might be a bit -- umm ... provincial.   It's true s
o
> long as you summarily ignore any environment in which it's false, and ther
e
> are environments in which it is not only false today but has been false fo
r
> something over four decades.
>
> I'd be hard-pressed to find any assembler code in your average Unisys MCP
> shop.  There's none in the operating system, the support libraries, the
> application support stuff (like the data base access routines), or the
> compilers, and Unisys not only doesn't provide, but actively discourages t
he
> third-party development of, assemblers for the system.
>
>     -Chuck Stevens
>
>

Chuck Stevens writes ...

>
>"S Comstock" <scomstock@aol.com> wrote in message
>news:20040707143232.11581.00001180@mb-m11.aol.com...
> 
>
>I think this statement might be a bit -- umm ... provincial.   It's true so
>long as you summarily ignore any environment in which it's false, and there
>are environments in which it is not only false today but has been false for
>something over four decades.
>
>I'd be hard-pressed to find any assembler code in your average Unisys MCP
>shop.  There's none in the operating system, the support libraries, the
>application support stuff (like the data base access routines), or the
>compilers, and Unisys not only doesn't provide, but actively discourages th
e
>third-party development of, assemblers for the system.

Well, you're right, of course. As Bill Klein says, I'm pretty much a z/OS
applications guy, some knowledge about VM and VSE (long time since I worked 
on
it), and no knowledge about what some of us ex-IBM'ers call "brand x" [i.e.:
anything other than big blue iron].

So, that's my bias, what I was "raised with", and I know it is not the whole
world, and I recognize and even appreciate the presence of brand x stuff, an
d
your contributions, particularly, to this newsgroup have certainly been
appreciated, even by me.

Regarding Bill's comments about my COBOL classes: at one time I used to incl
ude
platform-specific information about every platform I could find docs on, but
 I
had no interest from customers in the non-IBM stuff (not surprising,
considering the circles I tend to hang around in, so it's sort of a
self-fullfilling prophecy). Last w another instructor was teaching one of
 my
COBOL debugging courses for an OS/390 customer and even the labs setups woul
d
not run without extensive mods: they are a Librarian and Roscoe shop and my
setups are all written in TSO REXX / Dialog Manager. The point of all this i
s
that the reality is, even my pseudo-generic COBOL stuff really is designed f
or
the z/OS environment and a non-IBM user would quickly become aware of that a
nd
feel at least somewhat out of synch.

Once upon a time, one could be a generalist in this field and keep track of 
it
all. That time is long since gone for me, although there are some people on
this list (and some other lists) who seem to have a pretty solid handle on a
wide range of platforms. All we can do is all we can do, and ya' gotta' keep
learning new stuff, and there is never enough time to learn it all anymore.

Kind regards,



-Steve Comstock
800-993-9716
303-393-8716
www.trainersfriend.com
email: steve@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:l6zIc.152$mL5.148@newsread1.news.pas.earthlink.net...

> To clarify,  I think that Steve's course offering are intended ONLY for
IBM
> mainframe shops.

That much I was able to glean much later in the posting.  The quotes I was
addressing were the subject line and the first line of the message, "Well,
it's true, every shop does have some Assembler code somewhere."

It may be true that every shop *to which he might market his software* has
some Assembler code.  It may also be true that every shop *in which he has
any interest* has some Assembler code.

But I have to admit discouragement that contributors to comp.lang.cobol are
so quick to dismiss the relevance not only of Unisys' (and Burroughs' and
Sperry Univac's) contributions to the history of COBOL over nearly the last
five decades but also the continuing presence of Unisys MCP and Unisys
OS2200 environments not just in the US but worldwide.  I'm not as familiar
with the marketplace of the OS2200 environments, but I can say that Unisys
MCP systems running applications written in COBOL represent a significant
presence worldwide, probably most prominently in the financial marketplace.


> Much of what he offers for COBOL would *probably* be usable for other
COBOL
> environments, but (as far as I know) are certainly NOT tailored
(targeted?) for
> such.

Well, that's my point.  I have no objection to the product, nor do I intend
to denigrate in any way the value of his product *to those shops to whom it
would be useful*.  However, that set of shops is not *every shop*.

I don't even mind sloganeering, but repetition of the slogan as *universal*
truth rather than clarifying the context in the repetition is a tacet
dismissal of any possible counterexample shops from outside the "every shop"
set.

-Chuck Stevens

Here in comp.lang.cobol,
"Chuck Stevens" <charles.stevens@unisys.com> spake unto us, saying:

>I'm not as familiar with the marketplace of the OS2200 environments,
>but I can say that Unisys MCP systems running applications written in
>COBOL represent a significant presence worldwide, probably most
>prominently in the financial marketplace.

I've seen A-series boxes in the strangest places.  Two of my more recent
interviews were with companies which were fairly small, but which still
heavily used COBOL on an MCP box to run a number of key applications.

I wish more OS2200 shops existed, though.  :-)  At least locally, the
only two I know of are Unisys itself and NWA, and neither one of them
seem to be hiring (the latter for obvious reasons).

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) sing employment.
See web site above for resume/CV and background.

"Richard Steiner" <rsteiner@visi.com> wrote in message
news:NMt8ApHpvKOY092yn@visi.com...

> I wish more OS2200 shops existed, though.  :-)  At least locally, the
> only two I know of are Unisys itself and NWA, and neither one of them
> seem to be hiring (the latter for obvious reasons).

The Unisys home page has links to case studies for ClearPath and
ClearPathPlus servers that appear to me to be pretty evenly distributed
between OS2200 and MCP environments, although I can't really address their
geographic distribution, nor do I have access to a larger list of OS2200
clients (or how that list compares in either number or "basic average shop
size" to the MCP list)!

The MCP systems have historically covered a very wide object-code-compatible
range of performance; indeed, I believe that range is wider than any of its
competition, covering everything from extremely powerful enterprise servers
to laptop-based demonstration and development systems and everything in
between.   These systems also were actively marketed as upgrade paths for
ex-Burroughs-architecture systems such as the B1000, B2/3/4000, and V Series
systems occupying the small-to-medium enterprise environments (and in the
case of B4000 and V series, some pretty large ones too!).

The OS2200 has been, and I believe remains, popular in the powerful
enterprise server market.  I don't think it's had as much impact in the
medium-sized and smaller shops, and part of that may have been simply
because I don't think Unisys (or Univac) marketed it as a replacement
architecture for any other product offerings (for example, the ex-RCA
architectures or even the 418 series).  Part of the reason such marketing
opportunities weren't pursuied as actively for the OS2200 architecture may
have had to do with the complexities of dealing with 8-bit bytes on a
36-bit-word system, but my opinion on this may be based on obsolete
information (I last worked on an 1108 in about 1970) or simple ignorance
(I've been working on Burroughs systems and their direct descendance pretty
much exclusively since 1974 and will admit some prejudice in their favor!).

-Chuck Stevens

Here in comp.lang.cobol,
"Chuck Stevens" <charles.stevens@unisys.com> spake unto us, saying:

>The OS2200 has been, and I believe remains, popular in the powerful
>enterprise server market.

All I know is that airlines like NWA and UAL still use them, and some
other large organizations like NASDAQ did not long ago (whether or not
they still do I have no idea).

>Part of the reason such marketing opportunities weren't pursuied as
>actively for the OS2200 architecture may have had to do with the
>complexities of dealing with 8-bit bytes on a 36-bit-word system, but

I don't think so (see below).  I think it was more a corporate culture
thing -- Sperry was more an engineering company than a marketing one
from what I've heard (I didn't join Unisys until 1988 so all I know is
what my betters told me <g> ).

>my opinion on this may be based on obsolete information (I last worked
>on an 1108 in about 1970) or simple ignorance (I've been working on
>Burroughs systems and their direct descendance pretty much exclusively
>since 1974 and will admit some prejudice in their favor!).

I really like what I've seen of the MCP environment, although I must
admit CANDE took a little getting used to.  :-)  Not a bad editor for
its time, and considerably better than some of the stuff I've seen on
the 2200 side (though I wish a multiwindowed fullscreen editor like
UEDIT existed for the A; if it does, the shop that I worked in didn't
have a copy).

Anyway...  ASCII data on a 2200 is typically stored in quarter words
(9-bits per byte), but it usually isn't a factor for the applications
programmer, though that does somewhat depend on the specific language
being used.  As Fortran 66 programmers with no CHARACTER data type we
tended to care a lot.  :-)  But a 2200 COBOL programmer uses PICTURE
clauses for most things which look just the same as anywhere else.

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) sing employment.
See web site above for resume/CV and background.

As an fyi for OS2200 systems - I think you'll find some assembler code on
many of those systems, particularly if they still run a lot of basic-mode
ACOB (COBOL 74) code. In the extended mode environment, Unisys has done a
much better job of removing the need for most assembler code. The manuals
even go so far as to say that user written extended-mode assembler code is
essentially unsupported (although it can be done of course). Many of the
previously common needs for assembler have native language CALL interfaces
and other bits can now be accomplished using UC and doing interlanguage
calls. One could argue that something like the UCSGENERAL$ interface to
basic mode ERs isn't much above assembler coding though. You still need to
get the ER manual and figure out what the register usages are, etc.

In my particular circumstance, I would say that in the ACOB arena we
probably had something between 30-40 assembler routines around. With UCOB, I
have had to create only one so far and that is a fairly esoteric situation
that is likely site-dependent. The others are now provided with UCOB or were
creatable using either UCOB or UC.

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:ccubh0$2t98$1@si05.rsvl.unisys.com...
>
> "S Comstock" <scomstock@aol.com> wrote in message
> news:20040707143232.11581.00001180@mb-m11.aol.com...
> 
>
> I think this statement might be a bit -- umm ... provincial.   It's true
so
> long as you summarily ignore any environment in which it's false, and
there
> are environments in which it is not only false today but has been false
for
> something over four decades.
>
> I'd be hard-pressed to find any assembler code in your average Unisys MCP
> shop.  There's none in the operating system, the support libraries, the
> application support stuff (like the data base access routines), or the
> compilers, and Unisys not only doesn't provide, but actively discourages
the
> third-party development of, assemblers for the system.
>
>     -Chuck Stevens
>
>

Chuck Stevens wrote:
> But I have to admit discouragement that contributors to comp.lang.cobol ar
e
> so quick to dismiss the relevance not only of Unisys' (and Burroughs' and
> Sperry Univac's) contributions to the history of COBOL over nearly the las
t
> five decades but also the continuing presence of Unisys MCP and Unisys
> OS2200 environments not just in the US but worldwide.  I'm not as familiar
> with the marketplace of the OS2200 environments, but I can say that Unisys
> MCP systems running applications written in COBOL represent a significant
> presence worldwide, probably most prominently in the financial marketplace.[/color
]

Of course, the 2200 side still releases MASM, and even has extended-mode
support for it.  The subject line, for us anyway, is true - we've got a
couple of pieces of MASM that are pretty important in our system.  (I'm
sure Mr. Comstock's lesson plans don't include dealing with 36-bit
words, though...  ;>  )


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~