Digging back into my mind for data from 1983:
Third National of Nashville (TNB) ran a bank data processing site in
Florence, AL. The main bank there was First National (FNB). TNB decided
to close up shop in Florence so FNB took their data processing in-house.
FNB did not have a data processing department before this.
I was one of three programmers hired by FNB for this new department. The
complete staff from the TNB site was hired by FNB with the permission of
TNB as the operational staff.
We converted the data from TNB in-house written code to a set of
programs from an Orlando base software provider Financial Software of
America (FSA), later bought by UCC to become part of the new UCCEL
company, later acquired by CA and so forth. The one system FSA did not
have yet, but we needed, was a loan processing package. (They were
writing it, but it was not yet available.)
TNB decided to give FNB the complete source for their Loan System. It
was in assembler and I was tasked to convert it from MVS (or what ever
at that time) to DOS/SIPO (predecessor to z/VSE).
What I found was interesting. The system used something called VISAM, or
"variable length ISAM". It was not a big problem to convert it to VSAM,
but here is the story I got about VISAM.
I was told that when IBM was looking for a replacement for ISAM, that
two competing groups generated two options for the replacement. One was
to become known as VSAM, the other was this VISAM product. Well, we all
know that VSAM was IBM's future. The main guy pushing VISAM got mad and
left IBM and ended up at TNB of Nashville. He was one of the main
programmers for their loan system (and maybe others). And, when he left
IBM he took his VISAM stuff, refined it and incorporated it into TNB's
software.
It's been a long time since I did the conversion. But, as I remember it,
the code was all based on macros in the assembler and was really clean.
Well, that's the story I got. I don't know if it as true or just BS, but
the VISAM product really did exist and was used for serious banking.
A side note: The source was provided to FNB as a tape backup from a
Panvalet library. I had to write a program to decompress the backup
(from MVS) into a DOS supported format to be stored in ICCF. That, in
itself, was a fun project and was not that hard in Cobol, once the
patten of the compression was determined.
Tony Thigpen
Boy, am I getting old.
Farley, Peter x23353 wrote on 3/30/20 7:54 PM:
That was an interesting and probably true VSAM story, or at least very easy to believe true. I had a similar
exposure to the "original" VSAM design from a lecturer in an "Operating Systems and
Design" course I took at a local technical college. The lecturer was, IIRC, an IBM Fellow (or had once
been one). He claimed that the original VSAM design was farmed out to a team of computer science theorists
who presented a design for what they named "Access Method 1" back to IBM. It would have completely
replaced ALL other access methods in the OS/MVS world with a single access method for all types of files.
The marketing team were horrified. "We can't sell this to our customers, it would
be a HUGE conversion effort for them and they will revolt and buy someone else's
systems!"
The lecturer then told us that the head of the marketing team reportedly took home the
AM1 design, blue-penciled out all the sophisticated parts and brought back the result as
what he called "Access Method Zero". The lecturer claimed that the resulting
AM0 document is VSAM as it was originally released.
Perhaps apocryphal, but it made sense to me at the time. Typical Blue thinking
of the age (mid-to-late 1970's I think).
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Tony Thigpen
Sent: Monday, March 30, 2020 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
As I said, there are some good things and bad things for each OS.
As to your question, if someone is using the file when the 5 hour job gets to
that point, then it just waits.
Deadly embrace is normally a function of poor design or bad scheduling.
When that happens we just beat our programmers so they don't do it again. :-)
But, if it is something that might happen, we just convert the VSAM file to
shareoption-4, which *WORKS* in z/VSE by letting multiple programs update the
VSAM file at the same time without any special programming by the programmer.
Unlike z/OS which never implemented shareoption-4 as documented in the original
design document.
(I had a conversation with a IBM guy that worked on the original VSAM code for
MVS(?) when he was at IBM. He said that they just ran out of time getting it to
work, so they changed the document so that it was the programmers
responsibility to lock/unlock, not the OS. The OS handled it the
lock/unlock/wait in DOS/VS). He tried to get them to do it right later, but
powers that be said it was out and could no longer be changed.)
Tony Thigpen
Charles Mills wrote on 3/30/20 6:00 PM:
Not beating up on VSE. ("My OS is better than your OS.") DOS/360 was my first
IBM OS.
But the negative -- what OS/360 was trying to avoid -- is deadly embrace. What
if that 5-hour job gets up to the end and then CANNOT allocate the VSAM file?
And worst case, what if the program that owns it is waiting on something the
5-hour job already owns?
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tony Thigpen
Sent: Monday, March 30, 2020 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Yes, before the EXEC card.
Actually, there is no 'allocation' of a file by z/VSE during the JCL
processing. The file is only 'allocated' once it is opened and
'unalocated' once the program closes the file.
For instance, if you have a 5 hour program, that just needs to update
a 'totals' VSAM file at the end of the 5 hours, as long as the program
does not open the file until it needs the file, any other program can
use, including updating, the file until that time.
So, basically, you 'own' the file only while you have it opened.
One ramification is that you can't create a file simply by having in
the jcl, like in z/OS. You have to open it to create it.
Tony Thigpen
Paul Gilmartin wrote on 3/30/20 11:05 AM:
On Mon, 30 Mar 2020 10:11:53 -0400, Tony Thigpen wrote:
Coming from the z/VSE world, some of the JCL stuff in z/OS just is 'weird'.
I understand that in z/VSE tne DD statementw precede the EXEC for the
step. Intuitive because allocation is done first.
1) In z/VSE, the conditional jcl statements are more logical, not
something akin to RPN.
2) Our SETPARMs are sequential. You can have multiple SETPARMs of
the same variable in the same step and intervening statements are
processed using the 'then value' of the SETPARM.
3) We can modify and even define SETPARM values via programs as a
way to pass information between steps.
Don't get me wrong, there are good things in both, but sometimes
issues with the underlying basics of each lead to strange 'higher level' items.
Working daily on z/VSE, z/VM and z/OS really get's confusing sometimes.
Even simple things like responding to a console message. z/VSE needs
the outstanding message number, followed by a space, then the
response. Yet, z/OS usually needs a comma where z/VSE had the space, but not
always.
-- gil
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
