ROSCOE tutorial needed

Hi,

We got a project recently which involves heavy usage of ROSCOE editor.
Nobody in our team has ever worked on ROSCOE. We have worked
extensively on TSO.

Has anybody done any mapping of TSO to ROSCOE functionality?

We wud be graeful if we an get a document of common commands

Thanks,

I do not have a mapping of TSO to ROSCOE, but I do have a document from a
somewhat old ROSCOE RPF training that I took. I would not be too put off my
it being old as most of it will still be applicable to current day ROSCOE.
Some of the examples give valid techniques even though you might not do the
example that way today because there is now a ROSCOE command that does the
job.  Unfortunately the document I have is not in machine readable format. I
would be willing to copy it and mail it to you, or to fax it to you. You
should be able to get ROSCOE manuals and there is also a 'help" command. I
will be glad to answer any questions that I can.

"sunny" <sachingupta1981@gmail.com> wrote in message
news:1145703087.314305.185440@u72g2000cwu.googlegroups.com...
> Hi,
>
> We got a project recently which involves heavy usage of ROSCOE editor.
> Nobody in our team has ever worked on ROSCOE. We have worked
> extensively on TSO.
>
> Has anybody done any mapping of TSO to ROSCOE functionality?
>
> We wud be graeful if we an get a document of common commands
>
> Thanks,
>

In article <1145703087.314305.185440@u72g2000cwu.googlegroups.com>,
sunny <sachingupta1981@gmail.com> wrote:
>Hi,
>
>We got a project recently which involves heavy usage of ROSCOE editor.
>Nobody in our team has ever worked on ROSCOE.

Kind of makes me wonder

A) How someone managed to sell a team for a ROSCOE-based project which has
no ROSCOE experience.

B) How someone managed to buy a team for a ROSCOE-based project which has
no ROSCOE experience.

>We have worked
>extensively on TSO.

Kinda makes me wonder why someone would volunteer to work on a project
involving heavy use of a tool with which they had no experience.

DD

<docdwarf@panix.com> wrote in message news:e2ehob$23h$1@reader1.panix.com...
> In article <1145703087.314305.185440@u72g2000cwu.googlegroups.com>,
> sunny <sachingupta1981@gmail.com> wrote: 

Many years ago I worked for IBM and we needed to use ROSCOE due to a
farcical set of circumstances which I won't go into here... As I was the
least busy person on our team at the time (and the latest to join) I got the
job of streamlining all our standard procedures and providing ROSCOE
procedures for them. (In those days these were called ROSPROCs, but I
understand that has changed now). I was given a reference card and told to
get busy.  It was fun. I had a great time (really, not being sarcastic...)
knocking up various procedures and trying them out. It was very easy and
anyone who has a knowledge of modern scripting (I didn't at that time as
there was no such thing) should have no difficulty. I think the only bit
that got a bit involved was where it interfaced to SPF screens, but even
that was straightforward after you did a couple.

ROSCOE is endearingly simple and fun to write.

A year or so later we had to move to TSO and everybody was sorry as ROSCOE
served us well.

>
> Kind of makes me wonder
>
> A) How someone managed to sell a team for a ROSCOE-based project which has
> no ROSCOE experience.
>

ROSCOE is trivial.

> B) How someone managed to buy a team for a ROSCOE-based project which has
> no ROSCOE experience.
>

ROSCOE is trivial.
 
>

Most folks with that background will learn ROSCOE in a day by reading the
Reference card and looking at a few Procedures.

> Kinda makes me wonder why someone would volunteer to work on a project
> involving heavy use of a tool with which they had no experience.

Good point. These are obviously confident people... :-)

Pete.

In article <4b017rFv089bU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:e2ehob$23h$1@reader1.panix.com..
. 

[snip]
 
>
>ROSCOE is trivial.

ROSCOE is a specific technical skill, Mr Dashwood, and not a matter of
Grammar, Rhetoric or Logic; by definition is it not of the Trivium.

> 
>
>ROSCOE is trivial.

So trivial that they learned it yesterday and the posting is already
out-of-date, I am sure... God Save the Me!

> 
>
>Most folks with that background will learn ROSCOE in a day by reading the
>Reference card and looking at a few Procedures.

Well... poor lad's wasting time posting here, it seems.

> 
>
>Good point. These are obviously confident people... :-)

Not always right but never in doubt, perhaps.

DD

<docdwarf@panix.com> wrote in message news:e2en3v$fai$1@reader1.panix.com...
 
>
> Not always right but never in doubt, perhaps.

Or perhaps people who know their skills are portable?

First 'major' contract programming engagement I got was for a major
insurance company in Illinois  (whose name I won't give but I will tell you
I was in "good hands") who was looking for someone to handle ANSI X12 EDI
format data, using IBM mainframe COBOL, with IBM DB2 database as the primary
applications data storage.

I had experience handling ANSI X12 data.

I knew COBOL, but I could barely spell "IBM", never having seen an IBM
mainframe.

DB2-brand DMBS was another stranger to me, although I had done some work
with other brand-name ESQL Cobol and DBMS.

I was able to convince the (then prospective) client that COBOL was
portable, ESQL was portable, an IBM Editor was an editor not unlike other
editors I had worked with, a compile is a compile; and that developing and
testing any application was hardware and operating-system independent.  I
essentially made them answer the question, "Do you want someone who can
recite syntax from memory but not understand the application, or someone who
understands the application but may have to refer the documentation from
time to time to get syntax quirks unique to their envirnoment?"

Bottom line: I spent nine months there; and both Allstate and I were pleased
with the results. When I decided to leave to return to Wisconsin for
personal reasons, they asked me to reconsider. (Nope, I wanted back to my
native side of the Cheddar Curtain).

As Pete says, 'tools is tools.'  If you understand fundamentals, your skills
are portable, even though you may have to do a 'sales' job to convince
prospects of this.

One of the negative byproducts of the 'modern' program development
environment is that the pointy-clicky-draggy-droppy-touchy-feely development
tools don't force progammers to learn fundamentals, meaning the skills they
develop are not portable, and they become utterly dependent on the
availability of specific brand name development tools to create anything.
Combine this with the general tendency to recruit programmers with "Computer
Science" degrees instead of "Three Years Industry Experience Other Than Data
Processing", it is any wonder we see so many examples of application
software which is technically brilliant but can't create invoices or sales
orders correctly?


MCM

In article <jeL2g.74482$dW3.43732@newssvr21.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
><docdwarf@panix.com> wrote in message news:e2en3v$fai$1@reader1.panix.com..
. 
>
>Or perhaps people who know their skills are portable?

Another possibility, perhaps... the World is full of them!

[snip]

>Bottom line: I spent nine months there; and both Allstate and I were please
d
>with the results. When I decided to leave to return to Wisconsin for
>personal reasons, they asked me to reconsider. (Nope, I wanted back to my
>native side of the Cheddar Curtain).

As my Sainted Paternal Grandfather - may he sleep with the angels! - used
to say, Mr Mattias, 'Never use yourself as a comparative, you'll only be
disappointed.'  What was requested here was not assistance for an
individual but for a team of unspecified size: 'We got a project
recently which involves heavy usage of ROSCOE editor. Nobody in our team
has ever worked on ROSCOE.'

>
>As Pete says, 'tools is tools.'  If you understand fundamentals, your skill
s
>are portable, even though you may have to do a 'sales' job to convince
>prospects of this.

An individual's learning-curve is one thing, especially one who learns as
'I' (in the sense that my Sainted Paternal Grandfather might have
intended) do... grab the manual, sit at the terminal, put in 10-hour days
and tell folks to 'take a hike' when they try to disturb me.  Teaching a
group has, quite frequently, a different learning-curve... quite the sales
job, indeed, to get the client to pay for that!

DD

Pete Dashwood wrote:
> <docdwarf@panix.com> wrote in message news:e2ehob$23h$1@reader1.panix.com.
. 
>
> ROSCOE is endearingly simple and fun to write.
>
> A year or so later we had to move to TSO and everybody was sorry as ROSCOE
> served us well.
> 
>
> ROSCOE is trivial.
> 
>
> ROSCOE is trivial.
> 
>
> Most folks with that background will learn ROSCOE in a day by reading the
> Reference card and looking at a few Procedures.
>

Will you be including a chapter in your book advising the hiring of
people with unrelated skillsets as a cheap alternative?

Pete Dashwood wrote:
> <docdwarf@panix.com> wrote in message news:e2ehob$23h$1@reader1.panix.com.
. 
>
> ROSCOE is endearingly simple and fun to write.
>
> A year or so later we had to move to TSO and everybody was sorry as ROSCOE
> served us well.
> 
>
> ROSCOE is trivial.
> 
>
> ROSCOE is trivial.
> 
>
> Most folks with that background will learn ROSCOE in a day by reading the
> Reference card and looking at a few Procedures.
>

Will you be including a chapter in your book advising the hiring of
people with unrelated skillsets as a cheap alternative?

Michael Mattias wrote:

> (snip)
> As Pete says, 'tools is tools.'  If you understand fundamentals, your skil
ls
> are portable, even though you may have to do a 'sales' job to convince
> prospects of this.
>
> One of the negative byproducts of the 'modern' program development
> environment is that the pointy-clicky-draggy-droppy-touchy-feely developme
nt
> tools don't force progammers to learn fundamentals, meaning the skills the
y
> develop are not portable, and they become utterly dependent on the
> availability of specific brand name development tools to create anything.

On the same floor where I work on IBM mainframe COBOL applications
there's another department that works on applications written in C for
Sun Solaris on X86 boxes.  A few years ago, they spent quite a bit of
time recruiting a very experienced programmer for a critical project.
On his first day, he learned that the standard editor he would be
using was vi.  He quit on the spot.

--
http://arnold.trembley.home.att.net/