Y2K Cobol Mainframe LA Los Angeles 
Author Message
 Y2K Cobol Mainframe LA Los Angeles

$39.00 ????????????????????????????????????????????????
Helen



Sun, 16 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

On Tue, 27 Jan 1998 19:41:55 -0700, "Ginseng Jones"

Quote:

>Sample Interview:

>Q: Can you spell COBOL
>A: C-O-B-A-L-L
>Q: What type of experience do you possess?
>A: I read that Teach Yourself COBOL in 21 Days book.

nice book, especially with sections on indexed files.

Quote:
>Q: What type of systems have you worked on?
>A:  I wrote some QBASIC programs.

$39/hr = ~20000 year w/benefits are the recruiters wages.

Quote:
>Q:  What is a S0C4?
>A:  To keep your foot warm.
>Q:  What is a S0C7?
>A:  Is that how many times Holyfield hit Tyson?

hmm. i took cobol, but never heard of these S0cx's...
is it a error of some type?




Sun, 16 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:

>>Sample Interview:

>>Q: Can you spell COBOL
>>A: C-O-B-A-L-L

>>Q: What type of experience do you possess?
>>A: I read that Teach Yourself COBOL in 21 Days book.

>nice book, especially with sections on indexed files.

That's nice, but did the book cover VSAM, JCL, CICS, IMS, DB2 as well as
learning to read dumps?  Or any treatment of DASD on IBM MVS systems?
Writing a PC COBOL program to calculate a mortgage might impress your
family, but without any knowledge/experience of the platform (Mainframe
means IBM means MVS) that these programs run under really only gets you half
the way there.  It is a good start, though!

Quote:

>>Q: What type of systems have you worked on?
>>A:  I wrote some QBASIC programs.

>$39/hr = ~20000 year w/benefits are the recruiters wages.

>>Q:  What is a S0C4?
>>A:  To keep your foot warm.

>>Q:  What is a S0C7?
>>A:  Is that how many times Holyfield hit Tyson?

>hmm. i took cobol, but never heard of these S0cx's...
>is it a error of some type?

These are MVS OS System ABEND codes ...


Thu, 20 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:

>That's nice, but did the book cover VSAM, JCL, CICS, IMS, DB2 as well as
>learning to read dumps?  Or any treatment of DASD on IBM MVS systems?
>These are MVS OS System ABEND codes ...

1)  A newbie reading the manuals and posts here and on bit.listserv.ibm-main
might think VSAM is losing favor to DB2 (or QSAM?).  Is this true?
I'll keep ploughing through the manuals, but any comments will be
read and appreciated.

2)  A newbie, like me, reading TYCob21Days or just starting to get
into the Murach & Associates books might not be clear on how filesystems
are implemented in MVS.  First of all, they're "data sets", not files.
Secondly, file creation and access seems to be built into the COBOL
standard through the SELECT construct ;  record structure through the
FD construct.

I'm sure it'll turn up at www.s390.ibm.com, but I intuit
that *file naming conventions* are part of MVS.  Honestly,
I don't know (yet) what the Virtual Storage Access Method is.  
Obviously, it's a file-system designed to work as a sub-system
under an operating-system main-store paging scheme.

But, is it *the* MVS file system.  Is there even such a
thing at all?  There is the MS-DOS file system with its FAT and the Unix
file system with its inodes, but now we're talking *real* computers. :)

Would someone care to point out the manual that conceptually motivates
MVS data sets?  Would it be the ESA PoP?  Somewhere in MVS Base Elements?

3)  Thanks for the hint on SOCx.  I'ld suspected as much and already had
begun paging through the Messages and Codes disk.  I expect that i'll
stumble across it presently.

Thanks to everyone for past responses.  Mark Twenhafel.



Thu, 20 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:

(snip)
> But, is it *the* MVS file system.  Is there even such a
> thing at all?  There is the MS-DOS file system with its FAT and the Unix
> file system with its inodes, but now we're talking *real* computers. :)

> Would someone care to point out the manual that conceptually motivates
> MVS data sets?  Would it be the ESA PoP?  Somewhere in MVS Base Elements?

Big question, I'll do the best I can off the top of my head. In the
beginning (meaning 1965 or so) OS/360 had the following "access
methods":

BDAM    Basic Direct Access Method;
BSAM    Basic Sequential Access Method;
QSAM    Queued SAM;
BPAM    Basic Partition AM (aka PDS's, i.e., libraries, both source &
load);
BTAM    Basic Telecommunications AM;
QTAM    Queued TAM;

The Basic access methods were READ/WRITE/CHECK methods, no
blocking/deblocking, etc. The Queued AMs offered GET/PUT processing,
buffering, blocking/deblocking, etc. Later there appeared:

TCAM    Telecommunications AM;
VSAM    Virtual Storage AM(?);
VTAM    Virtual Telecommunications AM;

I know little about TCAM - it was dead by the late 80's (don't know when
it appeared). BTAM also died a natural death as VTAM handled more &
more, even on the DOS/VSE systems (all BTAM did in the first place was
to generate TP channel programs). VSAM & VTAM appeared in the early to
mid-70's when IBM introduced Virtual Storage (VS) to the computing
masses (I think) and were/are IBM's "strategic" access methods. Still
going strong today. This made VS a big deal, in spite of the fact that
Burroughs had offered it several years before (as early as the 50's?).

VSAM was the "ultimate" access method for DASD, i.e., key sequenced &
relative-record data sets (or files) replacing BDAM; entry-sequenced
data sets replacing BSAM/QSAM (although not completely, even today).
Linear data sets appeared later for DIV (Data in Virtual), and there's
another flavor of VSAM data set nowadays (don't remember what it's
called).

The various flavors of VSAM data sets are know by the following acronyms
(if you can't determine which is which, go directly to Jail, do not pass
GO, do NOT collect $200 <G>): KSDS, ESDS, RRDS.

If you want more detail on this (or other MVS topics) you could post
your question to 'bit.listserv.ibm-main'. There are people there who've
been working in the bowels of OS/MVS since day 1.

There is no one manual which covers all this. Check out the DF... (Data
Facility...) manuals. I'm sure someone else can suggest the best place
to start.

Sorry for any typos, hope you don't mind my tossing in the TP access
methods which have nothing to do with files & hope this is helpful,
Bill {*filter*}

(snip)



Thu, 20 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:

>  VSAM & VTAM appeared in the early to
> mid-70's when IBM introduced Virtual Storage (VS) to the computing
> masses (I think) and were/are IBM's "strategic" access methods. Still
> going strong today. This made VS a big deal, in spite of the fact that
> Burroughs had offered it several years before (as early as the 50's?).

The Burroughs B5000, introduced in 1961, was the first virtual storage
computer.  It had it's genesis in an overlay mechanism developed in
1959, some consider that the beginning of virtual storage, but it wasn't
available to the masses until 1961.
--

L  |/  

v  | \  1-818-985-3259                       Please reply without spam
e    |\
Y    |/ Panic in the Year Zero Zero:  http://members.aol.com/PanicYr00
o    |\ The 28th Term Revealed:
u    |/                 http://members.aol.com/PanicYr00/Sequence.html


Thu, 20 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:
>1)  A newbie reading the manuals and posts here and on

bit.listserv.ibm-main

Quote:
>might think VSAM is losing favor to DB2 (or QSAM?).  Is this true?
>I'll keep ploughing through the manuals, but any comments will be
>read and appreciated.

While it is true that you won't see a lot of VSAM being used in today's
mainframe world, you must remember that IMS, DB2 databases are nothing but a
bunch of VSAM files.  For the most part, this is transparent to the
applications programer, unless you need to create and populate your own test
versions of the databases.  Data base administrators, on the other hand,
need to understand (in some cases) VSAM very well.  In many shops, other
groups hold this responsibility, although the pendulum is swinging back into
the "handle it yourself" mode.
DB2 is pretty simple ... all that you need to know (as a COBOL programmer)
is how to embed the SQL code into your programs (EXEC SQL  ...  END EXEC)
and some rudimentary SQL (SELECT, INSERT, UPDATE ...).  IMS is a little more
complicated (although, it too, depending on the installation's usage may be
simple also).

Quote:
>2)  A newbie, like me, reading TYCob21Days or just starting to get
>into the Murach & Associates books might not be clear on how filesystems
>are implemented in MVS.  First of all, they're "data sets", not files.
>Secondly, file creation and access seems to be built into the COBOL
>standard through the SELECT construct ;  record structure through the
>FD construct.

If you can get a hold of MVS JCL by Murach & Associates, they do a pretty
good treatment of MVS data sets, system catalog and storage and MVS in
general ... excellent book for the new mainframe programmer ... maybe even
more important than a COBOL book (... I always think that if you can program
in one language, you can program in any ... given you take the time to look
at existing, running code and learn to adapt ...)

Quote:
>I'm sure it'll turn up at www.s390.ibm.com, but I intuit
>that *file naming conventions* are part of MVS.  Honestly,
>I don't know (yet) what the Virtual Storage Access Method is.
>Obviously, it's a file-system designed to work as a sub-system
>under an operating-system main-store paging scheme.

There is a Murach & Associates book for this too, no actually 2.  I wouldn't
bother with the one for COBOL - most shops now are using some form of
relational (DB2) or hierarchical (IMS) database platform.  If you ever have
to work with VSAM datasets, you usually copy some other JCL ...
Quote:

>But, is it *the* MVS file system.  Is there even such a
>thing at all?  There is the MS-DOS file system with its FAT and the Unix
>file system with its inodes, but now we're talking *real* computers. :)

>Would someone care to point out the manual that conceptually motivates
>MVS data sets?  Would it be the ESA PoP?  Somewhere in MVS Base Elements?

>3)  Thanks for the hint on SOCx.  I'ld suspected as much and already had
>begun paging through the Messages and Codes disk.  I expect that i'll
>stumble across it presently.



Thu, 20 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

At the NY Show (IEEE ?) in 1956 IBM handed out buttons that pronounced:

                "VIRTUAL is its own reward"

to announce virtual memory.

(Wish I knew what happened to that button)

In 1954 or 1955, the big button was:

            "Beware of things that go DBOMP in the night"

Quote:


>>  VSAM & VTAM appeared in the early to
>> mid-70's when IBM introduced Virtual Storage (VS) to the computing
>> masses (I think) and were/are IBM's "strategic" access methods. Still
>> going strong today. This made VS a big deal, in spite of the fact that
>> Burroughs had offered it several years before (as early as the 50's?).

>The Burroughs B5000, introduced in 1961, was the first virtual storage
>computer.  It had it's genesis in an overlay mechanism developed in
>1959, some consider that the beginning of virtual storage, but it wasn't
>available to the masses until 1961.
>--

>L  |/  

>v  | \  1-818-985-3259                       Please reply without spam
>e    |\
>Y    |/ Panic in the Year Zero Zero:  http://members.aol.com/PanicYr00
>o    |\ The 28th Term Revealed:
>u    |/                 http://members.aol.com/PanicYr00/Sequence.html



Fri, 21 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:

> While it is true that you won't see a lot of VSAM being used in today's
> mainframe world, you must remember that IMS, DB2 databases are nothing but a
> bunch of VSAM files.

Not true for IMS.

Some kinds of IMS databases use VSAM to implement indices.  Others
(HDAM for example) are completely independent of VSAM and do not even
resemble it.

I am not so familiar with DB2.  I have heard that the underlying
file structures are implemented through VSAM, but that the physical
organization of the VSAM datasets bear no simple or obvious
relationship to the logical organization of the tables.  As you
point out, knowing that VSAM is involved is not likely to be very
useful unless you are a DBA or systems programmer.

[snip; attribution for the following is lost:]

Quote:
> >I'm sure it'll turn up at www.s390.ibm.com, but I intuit
> >that *file naming conventions* are part of MVS.  Honestly,
> >I don't know (yet) what the Virtual Storage Access Method is.
> >Obviously, it's a file-system designed to work as a sub-system
> >under an operating-system main-store paging scheme.

[more snippage]

I believe VSAM stands for Virtual *Sequential* Access Method
(emphasis added).  Mainly it's IBM's way of implementing indexed
files, and supercedes the older ISAM (Indexed Sequential Access
Method) technology.  It has nothing specifically to do with paging
or virtual memory, despite the presence of the word "virtual" in the
name.

In brief, VSAM breaks up a data file into blocks, called "control
intervals" or "CIs" in IBMese, and typically stores multiple records
per CI, in key sequence.  A CI may be full or it may contain unused
space.  The unused space allows for the insertion of additional records
without disturbing more than a single CI.  When a CI becomes full,
another addition requires VSAM to split the CI into two partly-empty
CIs.

A separate index file keeps track of where the individual records
are according to a primary key.  Additional index files may map
alternate keys to the primary key, thereby enabling access by any of
multiple keys.  By consulting the indices, the access method can
access the records either sequentially (by key sequence) or randomly.

The above describes KSDS -- Key Sequenced DataSets.  There are also
Entry Sequenced DataSets and Relative Record DataSets, but these are
less commonly used, so far as I know.

There's more, and I probably garbled some of the details.  I was
waiting for someone to give a better description, but no one did.


http://home.swbell.net/mck9/cobol/cobol.html



Fri, 21 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:



(snip)

Quote:
> I believe VSAM stands for Virtual *Sequential* Access Method
> (emphasis added).

"OS/390

MVS Programming: Callable Services for High-Level Languages

Document Number GC28-1768-03"

Defines VSAM as "virtual storage access method".

Bill {*filter*}

(snip)



Fri, 21 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

On Sun, 1 Feb 1998 00:13:24 -0700, "Ginseng Jones"

Quote:

>>nice book, especially with sections on indexed files.

>That's nice, but did the book cover VSAM, JCL, CICS, IMS, DB2 as well as
>learning to read dumps?  Or any treatment of DASD on IBM MVS systems?
>Writing a PC COBOL program to calculate a mortgage might impress your
>family, but without any knowledge/experience of the platform (Mainframe
>means IBM means MVS) that these programs run under really only gets you half
>the way there.  It is a good start, though!

you would be hard pressed to find any book which covers all
those subjects.

furthermore, i really dont enjoy having to learn
2 database languages (vsam / db2) with cobols
indexed file features, and other system
specific things, such as CICS' tp monitor, a job control
language, or IMS.

once you have learned these 5 things, you might as well
simply just program in C, which allows you all
these low level services encapsulated in the *same* language.




Fri, 21 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:


> > I believe VSAM stands for Virtual *Sequential* Access Method
> > (emphasis added).

> "OS/390

> MVS Programming: Callable Services for High-Level Languages

> Document Number GC28-1768-03"

> Defines VSAM as "virtual storage access method".

> Bill {*filter*}

I stand corrected.  I spent about 20 minutes in Book Mangler looking
for a definition for the acronym, and never found one.  (I still like
my version better -- it's a pity that it's wrong.)


http://www.*-*-*.com/



Sat, 22 Jul 2000 03:00:00 GMT  
 Y2K Cobol Mainframe LA Los Angeles

Quote:



>> > I believe VSAM stands for Virtual *Sequential* Access Method
>> > (emphasis added).

>> "OS/390

>> MVS Programming: Callable Services for High-Level Languages

>> Document Number GC28-1768-03"

>> Defines VSAM as "virtual storage access method".

>> Bill {*filter*}

>I stand corrected.  I spent about 20 minutes in Book Mangler looking
>for a definition for the acronym, and never found one.  (I still like
>my version better -- it's a pity that it's wrong.)


> http://www.*-*-*.com/

Should you (or anyone else) care, the following is the definition out of the
COBOL for OS/390 and VM Programming Guide (online version):
(I looked when I first saw this post - thinking that it was sequential not
storage.  Then I looked in the VS COBOL II glossary and it also has
"storage" - so I guess it has been that way for a while).

"VSAM (Virtual Storage Access Method). A high-performance mass storage
access method. Three types of data organization are available: entry
sequenced data sets (ESDS), key sequenced data sets (KSDS), and relative
record data sets (RRDS). Their COBOL equivalents are, respectively:
sequential, indexed, and relative organizations."

P.S. I am sending a "readers Comment" form in on this definition - because
it pretends that there isn't such a thing as "linear" VSAM data sets - just
because COBOL has a hard time dealing with them.

----------------------------------------------------------------------------
----



Sat, 22 Jul 2000 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. COBOL Programmers Y2K mainframe for Los Angeles

2. COBOL (VSAM) Los Angeles - needed

3. Paid WEB Site study for COBOL Programmers in Los Angeles/Sunnyvale

4. ***COBOL Programmer Needed in Los Angeles***

5. Smalltalk job in Los Angeles

6. $$$$$Dallas/Los Angeles Career Opportunities$$$$

7. information on Los Angeles area UG

8. Seattle, Los Angeles

9. ST positions in Seattle, San Francisco, Los Angeles

10. Los Angeles Calf Smalltalk

11. (JOB) LOS ANGELES CALF SMALLTALK Project Manager

12. Smalltalk VisualAge Contractors - Los Angeles

 

 
Powered by phpBB® Forum Software