osfree.org

#765 From: Dale Erwin <daleerwin@...>
Date: Fri Aug 29, 2003 9:10 pm
Subject: Re: Alot of Acitivity and Alot of Discussion. dale_erwin
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Lynn H. Maxson wrote:
>
> I hadn't really wanted to touch off a discussion about COBOL.

I just want to say one more thing... not really about COBOL, but using
COBOL as the language of reference, because I think it's germane to
the 4GL discussion.

The advent of the structured programming paradigm, while beneficial from
a maintenance point of view, caused a lot of COBOL code to be placed
in a separate paragraph to simplify the logic flow, as it represented
one logical task. But many of these paragraphs were only PERFORMed
_one_ time by a "driver" paragraph. This may have been the reasoning
behind the optimizer's copying the PERFORMed code in line. Of course,
the real benefit of "reusability" is code that can be called/performed
from a number of different places. I was always somewhat amused by the
programmer who made all those paragraphs which were only called once,
and at the same time put code that could have been reused inline every
where it was used.

I also have a comment about "object-oriented" programming (OOP). It is
probably badly named (like many IT "objects" e.g. CICS... how in
the world could anyone divine what that system really does from its name,
Customer Information Control System?), but the concept of OOP is rather
difficult to grasp for someone (like me) with a background in procedural
programming languages. After my retirement I set out to learn Java for
my own satisfaction. Now, after coding in Java for about two years (I
realize it would have been faster in a work-related context), I am
finally comfortable with the concept.

Before anyone feels the need to enlighten me, I am aware that CICS was
originally conceived as a Database System, in fact a Database System
of BDAM (DAM to DOS/VSEers) files, but today BDAM/DAM is not even
supported, and its function as a Transaction Server is its principal
function followed closely by Data Communication for both IMS and DB2
database systems. In fact, I once heard that there are more shops
that use CICS as a DC component to IMS than there are that use IMSDC.

Finally, about the programmer having the last word: a theoretically
sound concept, but in reality there are too many programmers who could
mess up a wet dream. There are lots of talented programmers out there,
and I have known quite a few, but the others far outnumber them. This
is further exacerbated by the inept, unknowledgable managers who hire
them without the ability to know the difference.
--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439

#766 From: Dale Erwin <daleerwin@...>
Date: Fri Aug 29, 2003 10:49 pm
Subject: Re: Alot of Acitivity and Alot of Discussion. dale_erwin
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Lynn H. Maxson wrote:
>
> We achieve this through a data repository/directory, in this
> instance based on using a relational database, in which we
> store only the individual statements as rows in a table. To do
> that the software assigns each statement a name based on
> the first 20 bytes of its content appended by a 4-byte
> (binary) index value. The index value compensates for the
> possibility of homonyms (same name, different referents).
> Together they form a 24-byte unique name required for every
> row in a table.

Now THIS is intriguing. I like it already.

> Now note that the programmer writes statements as he would
> normally without concern for their existence in the database.
> The software will process a statement, create a name based
> on its content, check it against same names (homonyms) in
> the database, and check its total content against that of the
> other homonyms. If it finds a match, it will use that existing
> name for the source. Otherwise it will add a index suffix to
> give it a unique name and store it in the database.

What about the way some people phrase things differently? In fact the
same programmer may not code the same sentence the same way twice. Of
course the restrictions of the language syntax could prevent that, but
what about references to data? How could that always be expected to
be stated in the same way for the same piece of data?

> All this is invisible to the programmer. All he sees is the
> unaltered source. Now he could look to see if the source
> statement he wants is in the database, but that would take
> longer than simply writing it. So he just writes it. The
> software assumes all responsibility from that point on. Note
> that statement reuse is automatic, requiring no effort on the
> part of the programmer. Also note that any statement
> appears only once in the database, the data repository,
> regardless of how many times it appears in how many
> programs.
>
> You can write the input in any order. The software will
> determine (generate) the output order. Thus you can accept
> user changes/requirements as they occur, write them as
> specifications, insert them into the input, and the software
> will regenerate the output reflecting changes to the input.
>
> Now I said that kind of fast, but not fast enough for the
> software which can do all that tens of millions times
> faster.<g> If you have followed this to this point--and if you
> have not, go back and do so--and you have any kind of
> experience in the difficulties of source program maintenance
> of third generation languages, you have just seen what a
> difference a fourth makes.<g>

It is a LOT to digest. I have already read your message three times,
and each time, I find a point I missed the time before. But I must
say that the concept is fascinating.

> If you understand the meaning, the implication (and
> simplification) of all these features and functions in a single
> tool, you're not the only one. Intelligent people following the
> same logic come to the same conclusion: you only need one
> comprehensive tool, one user interface, and one form of
> source writing translating one form of user requirements. You
> now see why the software tool vendors offered lip service
> coupled with passive resistance to IBM's proposed AD/Cycle.

As many times as I have read about AD/Cycle, I never saw anything
like what you are describing. I had no idea... is this another
example of IBM's stealth marketing?

> You may also come to understand why my friend and
> collaborator Bob Blair has his focus on developing the front
> end which includes the data repository/directory while I
> prattle on the back end which produces all these visual and
> text outputs. In the middle we have our "smartest" editor for
> maintaining our unordered input source specifications, which
> get checked against the front end and processed by the back.

This brings up another question I already asked. You sometimes say
that the software doesn't exist, and other times you say something
does exist. Do you mean it just doesn't exist for the OS/2 platform?
Does this preceding paragraph mean that this is under development at
this time by you and your friend? If so, is it as an IBMer? And if
so, is it ever likely to reach the OS/2 platform?


> I thank you for your patience.

Patience, schmatience, you've whetted my appetite, and I hope that of
many others. I want it. When can I have it?

One other question: This sounds like something that might require a
"supercomputer" of sorts. But then, today's desktop machines are orders
of magnitude faster and have greater capacity than the mainframes I
worked on in '80s. And the speed and capacity are growing ever larger.
The first mainframe I worked on only had 4MB of real storage. Of course,
my first microcomputer only had 8KB. The times they are a-changing.

--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439

#767 From: "Lynn H. Maxson" <lmaxson@...>
Date: Sat Aug 30, 2003 12:11 am
Subject: Re: Alot of Acitivity and Alot of Discussion. lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Dale Erwin writes:
"...Finally, about the programmer having the last word: a
theoretically sound concept, but in reality there are too many
programmers who could mess up a wet dream. There are lots
of talented programmers out there, and I have known quite a
few, but the others far outnumber them. This is further
exacerbated by the inept, unknowledgable managers who hire
them without the ability to know the difference."

You have to understand I've been with CICS since its first
release. I probably differ with you on a few points,
specifically with reference to BDAM. What needs saying I
think is that CICS is a guest OS layered as an application on a
host OS. As a result the application is written using CICS API's
exclusively. Not wanting to upset anyone's applecart but it
means that the applications, (COBOL, PL/I) were portable
across platforms, at least any which hosted CICS. Unlike the
JVM no performance hits occurred in CICS due to this layering.
In fact that accounts for why more MVS and VSE accounts
used CICS/DL/I. I'm not going to put down IMS/DC, but I will
raise CICS.

As to your comments on programmers, I couldn't agree more.
Unfortunately some manage to screw up even in PASCAL
where Wirth sought to manage their excesses. Sometimes you
have to look not simply outside the box, but to logically
extrapolate ahead to what exists if something comes to pass.

If you buy the 80/20 rule, that 80% of the software work is
done by 20% of the programmers, then you have to think
what happens (best case<g>) when you increase productivity
by a factor of 5. Out of a staff of 100 (to keep this simple)
you only have to retain 20. Now increase that by another
factor of 5 (25 or 5 x 5 in aggregate). You only have to
retain 4. As you now have a homungous unemployed
population of experienced programmers you can hire a talent
agency to that other 16 out of a 100 that will not screw
up.<g>

I'm asserting a 50 times gain in productivity as a minimum. I'm
optimistic enough to believe that cream rises to the top in
programming regardless of "inept, unknowledgeable
managers". They will rise to the top, because if you only
need say five to replace the current 100, you don't need a
manager of any stripe. You allow a peer selection. I would
submit that you software quality and other benefits will
follow thereafter.

If you follow my logic about productivity, that it lies in
reducing the number of people required as well as the number
of tasks people perform, then when you add the capabilities
of the software tool, the Developer's Assistant, the cream will
not only rise to the top, but in fact will distance itself from
the remainder.

The net of this, if you choose to remain in this performance
and results-oriented arena, is that you better do it the way
"they" do or you are "outta here". I think that better tools
for better people will lead to better results.

IBM initiated something of this with its Chief Programmer Team
concept. That it didn't exactly take off like wildfire and in
fact disappeared ever so quickly out of sight lies in the fact
that accounts considering it quickly discovered how
ill-experienced their "senior" staff was. Damn few of them
could qualify. It therefore became a political issue. As such
management ducked a hot potato.

I was also a specialist in IBM Improved Programming
Techology. I witnessed many such evaluations. You could get
structured programming accepted, though in one case I had to
deal with someone who didn't want to go to extremes, saying
that he took care to program half structured and half
unstructured. When the manager asked what to do I said "fire
him".<g>

You could also get them to engage in structured walkthrus
(peer reviews) though never quite in the way IBM intended.
When it came to the librarian function, the transcription of
changes to the source written by the programmer, doing the
compilation, and then bringing the updated program listing to
the team, well, if you couldn't get chief programmers, you
couldn't have a chief programmer team. If you didn't have a
chief programmer team, you didn't need a librarian.<g>

Well, maybe two out of four isn't bad, but there is a fifth one
that slips my mind for the moment.<g>

I do remember the manager of the Hughes contract
programming staff coming to me after I did a presentation on
the improved programming technologies. He wanted to thank
me for showing that you could separate them out and select
which ones you wanted to implement, i.e. that it was a
loosely-, not tightly-coupled package. They too couldn't
accept the chief programmer team concept.<g>

#768 From: "Lynn H. Maxson" <lmaxson@...>
Date: Sat Aug 30, 2003 1:11 am
Subject: Re: Alot of Acitivity and Alot of Discussion. lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Dale Erwin writes:
"...What about the way some people phrase things differently?
In fact the same programmer may not code the same sentence
the same way twice. Of course the restrictions of the
language syntax could prevent that, but what about
references to data? How could that always be expected to
be stated in the same way for the same piece of data?"

In the first place remember in this instance at least we are
talking about a relational database manager and thus a query
language like SQL. If I wanted to find all references in the
source text table to the name "awol", that's a simple query in
SQL. I would have the choice of also retrieving the unique
name for the source text as well as its actual content (if not
fully contained in the name). So I could view all the uses in
source used throughout all applications within the enterprise.

I could then, again with the standard SQL, retrieve all the
statement assemblies using the different source statemens, all
the assemblies using them on up to getting a listing of all
programs in all application systems within the enterprise.

Now actually data names, which are referents, get stored in a
different table using the same software-assigned,
content-based, unique name system. Actually only the data
element names and attributes get stored. Their assemblies
exist as an ordered list of names of other assemblies or data
elements. This allows you to define structures, arrays, lists,
or unrestricted combination of either.

Remember your source statements are references to the
referents. Each are stored separately and individually. Each
support an unlimited (virtually) number of homonyms and
synonyms. For the data element table along with its
collection of assemblies allows the creation of a data
dictionary, which like a "regular" dictionary allows the same
name (referent) to have multiple meanings (homonyms).

"...As many times as I have read about AD/Cycle, I never saw
anything like what you are describing. I had no idea... is this
another example of IBM's stealth marketing?..."

Well, much like its often hyped HIPO documentation technique
in which its authors developed something without truly
understanding it, much the same occurred with AD/Cycle.
Remember AD/Cycle consisted of three vertical layers. The
upper layer contained the software development process
(SDP): specification, analysis, design, construction, and testing.
The middle layer contained the set of software vendor tools
marked out as line segments over the portions covered of the
upper layer.

The user community had all these different vendor tools, but
out of all of them it was impossible to make a selection which
offered a "seamless" path from "user requirements" to
"completion". In short the SDP offered a seamless flow from
one stage to the next, but not subset of the available tools
did. That meant the vendors had to somehow alter the length
of their product line segments mapped against the SDP such
that one product would begin where another ended. If this
occurred across the entire SDP, then the users could pick and
choose products that gave them their seamless flow.

Now in order to go from one product to the next seamlessly
(even considering the use of a concept like a UNIX "filter")
you had to have an agreement on the interfaces. Each
vendor tool was an IPO model with each "O" matching
exactly the next's "I".

So the vendors had to cooperate, redesign and implement
their line segments, and support these now standard,
agreed-upon interfaces. IBM for its part would supply the
storage area for these interfaces and the actual data for
input/output, called the data repository.

Well, it didn't take any vendor any time to see that he was
opening up his tenuous (and hard fought for) territory to
encroachment by his competition. They all said it was a good
idea, not wanting to anger the user community. They got
really polite with each other: "You first. No, you first."

As a result nobody went first. Thus no standard interface
established. No input or output data received. Without those
two you didn't have a data repository. If you didn't have a
data repository, you didn't have the rest. So IBM couldn't
offer a data repository because no one was willing to put
anything in it...until someone else did. So all the vendors could
point the finger at IBM for not having the data repository and
thus the principal cause of failure for the whole concept.

IBM for its part did its normal head up where the sun don't
shine when the situation got uncomfortable. IBM originally
would implement the data repository in OS/2, where at least
every user and vendor could afford at least one copy. Then
for some inexplicable reason it shifted gears, promising to
implement it in MVS only, where obviously not everyone could
afford a copy.

Now you will note that in my proposal only one "vendor" tool
exists, providing a seamless flow from user requirements
through testing. What people sometimes forget is that "
"seamless" means "one" from beginning to end. It's not an
"all-purpose tool", skimping somehow on any purpose.
Instead it is an all-in-one tool without skimping on anything.

"...This brings up another question I already asked. You
sometimes say that the software doesn't exist, and other
times you say something does exist. Do you mean it just
doesn't exist for the OS/2 platform? Does this preceding
paragraph mean that this is under development at this time by
you and your friend? If so, is it as an IBMer? And if
so, is it ever likely to reach the OS/2 platform?"

I try to make the point that I'm not inventing something new,
that all the pieces exist in one form or another in software.
They just don't happen to "co-exist" as a seamless package in
this form. Now I will admit that it took me a while, several
iterations, to get the directory portion down to four tables.
But once there its standard relational stuff. You give up using
"files". In doing that the dam bursts, flooding in the
remainder.

Yes, it is under development. While my friend and I and
others are retired IBMers, it definitely is not an IBM project. In
fact I would expect IBM software and services to use every
means possible legally to insure it doesn't exist. If it does,
they are out of business. It's a consequence of the
productivity gains and the cost reduction. You see, even IBM
came to understand the consequences of a successful
AD/Cycle. In

#769 Re: [osFree] Alot of Acitivity and Alot of Discussion.
Expand Messages

Dale Erwin
Aug 29, 2003
Lynn H. Maxson wrote:

>
> You have to understand I've been with CICS since its first
> release. I probably differ with you on a few points,
> specifically with reference to BDAM. What needs saying I
> think is that CICS is a guest OS layered as an application on a
> host OS. As a result the application is written using CICS API's
> exclusively. Not wanting to upset anyone's applecart but it
> means that the applications, (COBOL, PL/I) were portable
> across platforms, at least any which hosted CICS. Unlike the
> JVM no performance hits occurred in CICS due to this layering.
> In fact that accounts for why more MVS and VSE accounts
> used CICS/DL/I. I'm not going to put down IMS/DC, but I will
> raise CICS.

With one exception: There were quite a few DOS/VSE shops that
would have liked to upgrade to MVS, but they couldn't do it
because CICS on DOS/VSE supports RPG but on MVS it does not,
and their accumulated inventory of RPG programs would not allow
them to migrate due to the excessive cost of recoding. And now
CICS even supports C/370, or whatever it's called now. I've
been out of the loop for 3 years now.


> I'm asserting a 50 times gain in productivity as a minimum. I'm
> optimistic enough to believe that cream rises to the top in
> programming regardless of "inept, unknowledgeable
> managers". They will rise to the top, because if you only
> need say five to replace the current 100, you don't need a
> manager of any stripe. You allow a peer selection. I would
> submit that you software quality and other benefits will
> follow thereafter.

I also believe cream rises to the top, but my experience has been
that it is only recognized internally, inside the programming circle.
As far as retaining only 5 of 100 programmers, something else comes
into play: Corporate Politics. The ones with the authority to get
rid of the chaff, would then be faced with the possibility of a cut
in their budget, and they're going to fight that with all they have.

> If you follow my logic about productivity, that it lies in
> reducing the number of people required as well as the number
> of tasks people perform, then when you add the capabilities
> of the software tool, the Developer's Assistant, the cream will
> not only rise to the top, but in fact will distance itself from
> the remainder.
>
> The net of this, if you choose to remain in this performance
> and results-oriented arena, is that you better do it the way
> "they" do or you are "outta here". I think that better tools
> for better people will lead to better results.
>
> IBM initiated something of this with its Chief Programmer Team
> concept. That it didn't exactly take off like wildfire and in
> fact disappeared ever so quickly out of sight lies in the fact
> that accounts considering it quickly discovered how
> ill-experienced their "senior" staff was. Damn few of them
> could qualify. It therefore became a political issue. As such
> management ducked a hot potato.

Exactly.

> I was also a specialist in IBM Improved Programming
> Techology. I witnessed many such evaluations. You could get
> structured programming accepted, though in one case I had to
> deal with someone who didn't want to go to extremes, saying
> that he took care to program half structured and half
> unstructured. When the manager asked what to do I said "fire
> him".<g>

Most corporate enterprises do not have managers who are qualified
to make such evaluations... granted they make them all the time,
but that's beside the point. So what happens then? Is one
evaluated by his peers? If so, someone is sure to get screwed.
It's really quite a joke. Dilbert lives!!

--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439

#770 Re: [osFree] Alot of Acitivity and Alot of Discussion.
Expand Messages

Dale Erwin
Aug 29, 2003
Lynn H. Maxson wrote:

>
> Yes, it is under development. While my friend and I and
> others are retired IBMers, it definitely is not an IBM project. In
> fact I would expect IBM software and services to use every
> means possible legally to insure it doesn't exist. If it does,
> they are out of business. It's a consequence of the
> productivity gains and the cost reduction. You see, even IBM
> came to understand the consequences of a successful
> AD/Cycle. In spite of their "vendor lip service" in support and
> the negative publicity of its failure, I'm sure it breathed a sigh
> of relief at dodging another bullet. You have to be careful
> what you ask for.<g>

Great! Is it an open-source project? Whatever kind of a project
it is, I wish I could be a part of it. Is there anything I could do
to help? If not, I'll just sit here plodding along with the Music
Notation program I am developing in Java.

I don't know if any of the developers were at one time privy to the
IBM source code for some of the languages you mention as background,
but if they were, would that open the way for legal action from IBM?
--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-643

#771 Re: [osFree] Alot of Acitivity and Alot of Discussion.
Expand Messages

Lynn H. Maxson
Aug 29, 2003
Dale Erwin writes:
"With one exception: There were quite a few DOS/VSE shops
that would have liked to upgrade to MVS, but they couldn't do
it because CICS on DOS/VSE supports RPG but on MVS it does
not, and their accumulated inventory of RPG programs would
not allow them to migrate due to the excessive cost of
recoding. And now CICS even supports C/370, or whatever it's
called now. I've been out of the loop for 3 years now."

Actually I had experience with two RPG accounts, both
repesenting upgrades from S/36 to S/370 VSE. In one they
wrote their CICS application using RPG. In the other, National
University, they had a complete S/36 RPG II online system
which they coverted to VSE, CICS, and PL/I. Having worked
with the Personal Application System under DOS which was
RPG form buried in a BASIC body, I could have written an RPG
to PL/I conversion program that would have allowed your VSE
shops to go to MVS. MVS is a horribly expensive software
upgrade relative to VSE. If it wasn't for the fact that nothing
matches it for throughput, it is otherwise a hard sell.

Yes, you can write CICS applications in C. I had a client,
Lockheed (Skunkworks), downsize from a mainframe to IBM's
R/6000 UNIX (AIX) using a non-IBM COBOL and a non-IBM
relational database. The COBOL programmer basically had no
CICS experience and had long fallen behind in the conversion.
The system didn't work. The client didn't know why. The
multiple vendors weren't willing to invest resources to
discover someone else's problem. As it turns out they were
correct. The one client person responsible for installing the
software worked essentially in isolation and was considered
above reproach. Unfortunately that same person with no
knowledge of the vendor software made installation decisions
that caused the problem. I had a four-day contract, subbing
to a sub in turn subbing to IBM. I dutifully informed the IBM
marketing rep responsible for the account that the client had
an UNIX administration problem, which I had determined was
the problem. I also told him that I was inexperienced in UNIX
administration. The marketing rep informed the client that I
was the wrong person for job. My job was to determine the
source of the problem and the fix necessary. I had done that.
The same person who had caused the problem, the UNIX
administrator, on installation was certainly capable of
applying the necessary fix. Needless to say that marketing
rep stayed clear of me. I would have decked the SOB. He had
a hot situation on his hands. I cooled it. Then he attempted
to nuke me.<g> It really hurts when you realize IBM kept him
and retired me.<g>

#772 Re: [osFree] Alot of Acitivity and Alot of Discussion.
Expand Messages

Lynn H. Maxson
Aug 29, 2003
Dale Erwin writes:
"Great! Is it an open-source project? Whatever kind of a
project it is, I wish I could be a part of it. Is there anything I
could do to help? If not, I'll just sit here plodding along with
the Music Notation program I am developing in Java.

I don't know if any of the developers were at one time privy
to the IBM source code for some of the languages you mention
as background, but if they were, would that open the way for
legal action from IBM?"

May I suggest that you subscribe to scoug-programming which
you can do at www.scoug.com. This is the SCOUG
programming SIG mailing list where basically this general
discussion is ongoing. I am going to speak at Warpstock in San
Francisco in October on "Opening Open Source", related to a
current SCOUG effort to find ways to get more of the OS/2
community into contributing to open source projects. What
we have been discussing here comes from a presentation I
made at Warstock 98 in Chicago where I introduced the
Warpicity proposal.

The proposal consisted of three parts. One part proposed a
fee-based ($20/year) international OS/2 organization where
the members operated as a "board of the whole". The second
part dealt with the technical staffing, consisting of the two
roles of communicator and developer. The third part dealt
with the methodology, the tool (Developer's Assistant), and
the language (SL/I) that the staff would use.

Unfortunately every one got fascinated with the tool and the
language, ignoring the organization and staffing parts. In
truth our most significant deficiency as a community is that
we aren't: we have no formally recognizable body. We have
no formal means of gathering user input, transforming them
into issues, discussing them, setting priorities reflecting their
overall value, voting on which to implement in what order,
and then paying a full-time staff with part-time volunteers to
bring them to fruition. In short to get into the "business" of
promoting OS/2.

Well, that has gone nowhere. At one time it sort of paralleled
the general goals of VOICE where I was a "founding"
participant in their WarpDoctor project. When after some 2+
years of continuous participation some newbies questioned my
motives and accused me of subversion I decided I had other
avenues I could travel.<g>

I joined OSFREE to create an OS/2 replacement. There a
division arose whether to pursue a microkernel approach or a
layered approach on a Linux host. The division led to a split
where the layered folks moved away from kernel issues to
the other parts of the OS/2 package. To support that they
formed this OSFREE mailing list.

From here they have recently formed two other "moderated"
mailing lists, one for documentation and the other for actual
coding. I haven't joined either. My basic position remains the
same: you cannot create and maintain an OS/2 replacement at
less people cost than IBM. It will take you longer to create it
due to the lack of organization and the unscheduled
availability of volunteer labor. When you create it you can't
afford to keep it up. The people cost are too high. They
were too high for IBM who lost billions before "downsizing" its
OS/2 effort.

I can see joining the documentation effort to help insure that
a complete design exists before writing source code. I could
see it except for tendency to jump ship and start coding. If
you think writing the code is hard work and time expensive,
wait till you have to rewrite it over and over.

I offered the Warpicity proposal as an open source project. I
didn't like the feeling of becoming indispensable to the
project. I happen to agree with Gerald Weinberg, who says
his first task as an IT manager is to find the indispensable
person and fire him. As a result I have focused on discussions
to any detail, to answer any question that people ask in hopes
of gradually through osmosis to engage as it were in a "skills
transfer" of these ideas to others. This would allow them to
pursue them on their own. In any decision that we might
make I would be relegated to one vote. That's my kind of
democracy.<g>

You see I know that as a community we cannot afford to
maintain OS/2 if IBM cannot, using the same methods as IBM.
It's not that we can't technically do it. It's that we can't
physically do it.

I've considered starting an open source project under Netlabs.
That, it seems to me, is a logical choice, the logical place.
However, you need more people first receptive to the idea
and the second having a real understanding of it. Once you
have achieved that skills transfer where everyone feels its
really "his" then you have peer support.

As a founding member of SCOUG where I have many OS/2
friends they tolerate my "eccentricities" well. I have more
recently brought the interested parties to where we have
become the Programming SIG. There I expect we will come to
a consensus on an approach once we have given everyone a
chance at the podium.

Every time a retired or former IBMer gets involved in a project
someone raises the issue of legal action raised on information
or experiences gained while an employee. To me it's FUD. It's
FUD because everthing discussed in these forums lies in the
public domain. The facts belong to everyone. There's no
trade secrets exposed, no copyright infringements, nor patent
violations. I think I've published enough in sufficient detail
publically to allow "prior art" to protect from future attacks.

Once a small cadre of people with a necessary understanding
of the systemic solution I propose exists, then I think we can
start it as a formal project. I get extremely nervous anytime I
hear something is "my" idea when I go to the effort to make
sure it's a gift, an idea that anyone is free to claim as a
starting point for future work. As I said I prefer a climate in
which I have only one vote.

#773 Re: [osFree] Alot of Acitivity and Alot of Discussion.
Expand Messages

Dale Erwin
Aug 29, 2003
Lynn H. Maxson wrote:

>
> Actually I had experience with two RPG accounts, both
> repesenting upgrades from S/36 to S/370 VSE. In one they
> wrote their CICS application using RPG. In the other, National
> University, they had a complete S/36 RPG II online system
> which they coverted to VSE, CICS, and PL/I. Having worked
> with the Personal Application System under DOS which was
> RPG form buried in a BASIC body, I could have written an RPG
> to PL/I conversion program that would have allowed your VSE
> shops to go to MVS. MVS is a horribly expensive software
> upgrade relative to VSE. If it wasn't for the fact that nothing
> matches it for throughput, it is otherwise a hard sell.

My last job before retirement was on a contract for IBM Global Services
in Santa Fe NM. We had a PC (it was called a PC, but it was a monster),
OS/2 based, and with a P390 processor card in it. We ran S390, CICS,
DB2, COBOL for MVS and VM, and High Level Assembler on it. We used that
machine for all our development, then migrated to the State of New Mexico's
3090 for production. I heard someone mention a price for all that software,
and I thought it was very low, but maybe being part of IBM they got a break.

> Yes, you can write CICS applications in C. I had a client,
> Lockheed (Skunkworks), downsize from a mainframe to IBM's
> R/6000 UNIX (AIX) using a non-IBM COBOL and a non-IBM
> relational database. The COBOL programmer basically had no
> CICS experience and had long fallen behind in the conversion.
> The system didn't work. The client didn't know why. The
> multiple vendors weren't willing to invest resources to
> discover someone else's problem. As it turns out they were
> correct. The one client person responsible for installing the
> software worked essentially in isolation and was considered
> above reproach. Unfortunately that same person with no
> knowledge of the vendor software made installation decisions
> that caused the problem. I had a four-day contract, subbing
> to a sub in turn subbing to IBM. I dutifully informed the IBM
> marketing rep responsible for the account that the client had
> an UNIX administration problem, which I had determined was
> the problem. I also told him that I was inexperienced in UNIX
> administration. The marketing rep informed the client that I
> was the wrong person for job. My job was to determine the
> source of the problem and the fix necessary. I had done that.
> The same person who had caused the problem, the UNIX
> administrator, on installation was certainly capable of
> applying the necessary fix. Needless to say that marketing
> rep stayed clear of me. I would have decked the SOB. He had
> a hot situation on his hands. I cooled it. Then he attempted
> to nuke me.<g> It really hurts when you realize IBM kept him
> and retired me.<g>

I find that a little amusing... not your predicament, but the whole
thing about Lockheed. I don't know what Skunkworks might have
reference to, but I have a very good friend who works for Lockheed.
He has been with them for probably 30 years now. He had just bought
a new house in Chatsworth when Lockheed moved from Burbank out to
Palmdale. He's still there, though, riding their shuttle 80 miles
or whatever it is each way from Chatsworth to Palmdale. He started
off programming in Fortran, but now I think he has moved to COBOL.
He will not own a PC. He says he wouldn't use the one he has at work
if he could find a 3278 somewhere. He's a little eccentric. I've
knowm him for years. After he got out of the Army after serving in
VietNam then going back to Nam for two years as a civilian, came back
to the States with a Vietnamese wife and told everyone he was working
as a mathematician. We were duly impressed, but when I finally graduated
from CSUN and started working as a programmer, I found out he was doing
the same thing. That was my second trip to college and I graduated at
the age of 48. The first trip I was a music major.

--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439

#774 Re: [osFree] Alot of Acitivity and Alot of Discussion.
Expand Messages

Lynn H. Maxson
Aug 30, 2003
Dale Erwin writes:
"...My last job before retirement was on a contract for IBM
Global Services in Santa Fe NM. We had a PC (it was called a
PC, but it was a monster), OS/2 based, and with a P390
processor card in it. We ran S390, CICS, DB2, COBOL for MVS
and VM, and High Level Assembler on it. ..."

Well, prior to the P/390 was the P/370. I have two of them at
the cost of $5000 each. At one time I had a complete bus and
tag cable system to attach the PC to a mainframe tape
controller. To download the software IBM gave us an
exemption to their standard customer contract forbidden such
activities. That particular business venture went down the
tubes.

Then my late business associate, Bob Chapman, leased a
P/390 system from IBM housed in an IBM Server model with
RAID support, MVS, COBOL, CICS, and all the rest. While we
used it successfully to fulfill several mainframe based
software products the biggest barrier to sales of the P/390
system came from IBMers. In one instance we wanted to
suggest to a client, SCE, to purchase one for software testing
purposes. The IBM team on the account informed us that any
attempt to do so would lead to their impeding our chances for
further software contract work at the account.

It's a little odd still to take the P/370 card out of its case to
see this PC-processor size chip, knowing its an IBM-certified
mainframe. As you are familiar with S/360/370/390 assembly
language you understand why someone would remain an
assembly language programmer on the mainframe and at the
same time avoid pursuing the same course on an Intel
architecture.

Your friend who commutes from Burbank to Palmdale
probably works at the Lockheed Skunkworks. It's a group
responsible for secret government projects like the stealth
bomber. In fact while they were still in Burbank and
considering downsizing we made a proposal to them to not
use a UNIX-based system, IBM's AIX, but to use the P/370
hosted on OS/2. That way when they downsized they would
not have any software conversions to perform. Then again, if
they had, I wouldn't have had the other contract.<g>

*************************************
I just check the archives on the SCOUG website. It still has my
Warpicity report. You can use the furnished search facility to
retrieve all references. You can just enter "maxson" and a
number of references will appear. I just began reading one
attributed to me which I never wrote. I think I recognize the
style of someone like Peter Skye who writes better than I
do.<g> In fact I am attributed to several articles actually
authored by others. I'm going to have to get that corrected
before people get the impression that I am a one-man
band.<g>

I need to publish something in more detail than a series of
chapters I did in Section 18, OS/2 projects, in the IBMFORUM on
Compuserve. People want to know more about SL/I and the
Developer's Assistant...and possibly the data
repository/directory. So maybe I should follow the same
advice I offered on this forum about documenting something
completely before engaging in implementation.