You got that right... for years we had a VS1-MVS-XA-ESA-OS/390-z/OS environment with a parallel VM/370-VM/SP-VM/ESA environment for doing development. Our change control was simple, our sources were based on 80-byte records, etc. Our online environments were CICS and a few home-grown DMS/CMS applications, batch was predominantly PL/I with ISAM (and later VSAM) files. Then we brought in a DBMS with a 4GL and built-in TP monitor. (Model 204). Life was still pretty good, although we started writing REXX applications and had to develop change control for that and the DMS/CMS code.
Eventually CMS went away - the programmers moved to TSO, the functional users (SCT Banner's term for "end users" or "lusers") moved to a combination of TSO/ISPF, Model204 applications, and web apps. But our mainframe change control processes still worked.
Enter Unix, in the guise of SCT Banner. Don't let anyone kid you, it's an ERP, and a big hairy mess. Many of our programmers are "back to square 1", having to deal with C, shell scripts, perl, etc rather than JCL, PL/I and User Language. Cobol is somewhat familiar ground, although "make" is a wierd construct to them and shell script drivers are copied by rote (they're used to DMS/CMS or ISPF applications building compile JCL).
Change control? Hah. We're so busy trying to get acclimated to the environment that the closest we have right now is ".old" and ".save" files laying around. I've installed SVN, but I'm too busy fighting fires to write the documentation, particularly since I'm one of the few people that truly *is* Unix-literate (but I can still build a CP nucleus if I had to!) I spent 2.5 hours tonight unsnarling Banner Job Submission and its interaction with Appworx.
Lately I've been buying music software and hardware, and http://www.bizrate.com/ has been good for me.
Twice recently I took quotes I got off of Bizrate into Guitar Center and they were willing to beat the price - but if not I had a decent deal available over the net - most recently I got a Presonus Firebox firewire audio interface for my laptop.
I used to support a usenet news server written in REXX (PSU NetNews), and had IRC, mail (Shaffer Mail), NNTP newsreader (NNR) and web browser (Charlotte) clients, all written in REXX.
There was also VM Gopher client and server, and I (just for fun) briefly ran a VM HTTPD written in REXX.
For those wondering why the mandatory comment, it was not a requirement to force documentation into a program (-:
EXEC, EXEC2, and REXX scripts shared the same common filetype (extension), "EXEC".
When the command processor went to execute an exec program, it looked at the first line. First lines beginning with a REXX comment were passed to the REXX interpreter. First lines beginning with the token &TRACE were passed to the EXEC2 interpreter. Otherwise they were passed to the original EXEC interpreter.
BTW, for the guy asking about the acronyms: VM/ESA (and VM/370 and VM/SP) were virtual memory operating systems (not unlike VMware) that allowed "bare metal" operating systems to share a single processor. VM would run underneath itself (very common when working on upgrades), and it was also used to support DOS/VSE, UTS (Amdahl's mainframe Unix), VS/1, and MVS variants.
CMS (Conversational Monitoring System) was the interactive environment that most users had to edit, print, compile, and execute programs. In addition, our MVS guest machines generally IPL'd (booted) CMS to do some setup, and the last line of their profile exec (autoexec.bat-like) was to boot the device that contained MVS.
z/OS (and forerunners OS/390, MVS/ESA, MVS/XA, MVS/SP, MVS and VS1) is essentially batch operating systems (not the best description really), but a batch job or started task (daemon) can run multiple-user TP monitors like TSO and CICS that allow people to interact over 3270 (block-mode) terminals and other connections. Database services under MVS included DB2, IMB, Model 204, IDMS (who remembers that one?) and others.
ISPF is the Interactive System Productivity Facility, a menu/panel/picklist/editor environment with file tailoring (template) processing. It's common in the TSO (Time-Sharing Option) environment, less so in VM. DMS/CMS was a CMS-only panel manager that had a lot less baggage than ISPF.
CUFS was College and University Financial System, an accounting package for higher ed. It was rolled into Advantage by the vendor, AMS, during the run-up to Y2K.
SCT is the vendor of Banner, essentially an ERP for colleges and vendors. It is very dependent on Oracle facilities (database, application server, and other services). My thoughts about the product are "not kind", mostly due to documentation and implementation schedule issues.
We (YSU - Youngstown State) installed 8.0 in January 1985. Initially we ran M204 under VM because our VS/1 system didn't have enough space for online M204 systems. That cleared up once we went to MVS/XA. We were a beta site for several releases, had site visits from Mary T & Alan Y.
Model204 under CMS has some nice interface features to REXX, although we never used it.
Alas, due to Banner, Model204 at our site is going the way of our VM & REXX code, but we'll have it for a few more years yet. M204-L has had recent discussion about "Another one bites the dust", but I haven't mentioned what we're doing yet.
I used to be the VM/ESA systems programmer (king geek) for a state university (I'm still at that university, it's been over 21 years).
REXX was the first serious scripting language that IBM delivered for VM (EXEC was awful and EXEC2 not much better). Our systems development (applications) staff wrote quite a number of in-house REXX applications interfaced to DMS/CMS (this was before ISPF was very usable under VM). Most of these were working with CUFS (later Advantage). I used REXX extensively to match-merge two files, generate reports, and reformat data. I also rewrote some programs in REXX that had originally been implemented in SNOBAT (a snobol4 dialect for System/370).
Roll forward a few years. All the sudden, I'm responsible for Unix servers as well as VM. Although I installed regina on our Unix servers, I figured out pretty quickly that perl was the preferred script language for Unix (I first installed 4.0.36). I saw that there were a lot of facilities and working scripts in perl that I'd have to build for myself in REXX, so I made a point to learn perl. I still used REXX for things that interacted with our VM/ESA and z/OS & TSO/ISPF environment.
Roll forward a few more years. IBM drops HESC, and VM becomes prohibitively expensive to keep. Meanwhile, our academia is moving to Unix and PC-based teaching, and a Unix-based ERP is on the horizon. We decided to eliminate VM. I spent quite a few hours writing perl scripts to parse DMS/CMS panel sources and REXX programs, to build ISPF panels and generate ISPF-friendly REXX from the DMS/CMS REXX code (fortunately most of the code was cookie-cutter so it was easy to do a find/replace). I knew these programs would be eliminated when the ERP was in place.
Now I'm so neck-deep in Oracle (database, application server, and other toys) and SCT Banner that I maybe spend 10 minutes a day on our z/OS system, and haven't written a new program there (in any language, much less REXX) in six months. I still maintain or help debug a REXX program now-and-then.
REXX was a success, but for us VM died. I still like REXX, but perl has pretty-well replaced it for me. The last time I wrote a REXX program I caught myself writing perl-isms into it that I had to fix.
We've had external auditors come through with their "best practice checklists" and ask us all kinds of questions, then they make their report to the ones that brought them in.
Two years ago, after the report went to the Board of Trustees (I work for a state university), we were tasked to give a "when or why not" to each and every issue on the report.
On the bright side, the particular auditor we've had to deal with most of these times was as fair and accurate as can be expected - there were no real surprises sprung on us (she's back next week to do our Oracle systems).
If I remember right, a couple of years ago Intuit removed the ability of QuickBooks to talk to any SMTP server but theirs - and you had to open an account with them for a monthly fee in order to send e-mailed invoices or bills through their server.
Then the Turbo-Tax/macrovision mess... now this...
I tried Quicken once, it was more hassle than it was worth. I do my bills over the internet via CheckFree, and I use HR Block Taxcut for my income tax.
State universities.
You won't get rich on options. Heck, you probably won't get rich, period. You may find yourself stretched a bit to cover a bigger chunk of products than you'd like. You most likely won't get relocation pay. But in many cases, you'll be in a stable, long-term job.
I've worked for YSU for 21 years. During that time my salary has close to tripled, to a very respectable wage for this area.
I've had opportunities to upgrade my skill set at the university's expense over the years.I started out as a systems programmer for VM/SP and VS/1, through a 3270-based database (Model 204) and VM/ESA and REXX applications, and now I'm a Unix system admin with some Oracle DBA responsibilities, as well as auxilliary products like Tivoli Storage Manager and using lots of open source products like Apache, Exim, and perl.
We have an entire staff (both technical/development staff and functional staff) presently retraining from the 3270 world to SCT Banner, an ERP package based on Oracle DBMS, Application Server, etc. In addition, we've recently hired for our Tech Desk, and some functional areas have their own tech people as well.
I'll probably regret saying this but the future of digital recording/editing will not use one computer. In the future you might use your laptop to run the software and have 2-3 computers networked in a different room running plugins and othe3r audio processes.,
No one really wants to work that way right now -- most audio professionals I know really dont understand the power behind distributed networking. It's not big yet, but it's already happening... on KVR I've read of guys using a Mac to control two or three PC's running Gigastudio (PC-only), people using VST System Link, FX Teleport, DMIDI, MIDI-over-LAN or just plain MIDI cables to link two or more PC's, etc.
Makes my setup (PSR-2000 with floppy drive, 2ghz pentium 4 and 1ghz laptop with appropriate sound cards and networked)seem pretty primitive by comparison.
Assuming you're on the Windows platform, I would suggest you check out FLStudio - it comes with some decent software synths (FLS calls them "generators") and also host many free virtual instruments ("vsti" and "dxi"), as well as shareware and commercial ones.
There are other choices as well - Orion (PC), Muzys (PC & Mac), Cubasis VST (PC & Mac) Tracktion (PC, Mac in beta), Massiva (PC), and Cakewalk Home Studio 2004 (PC) for example. A bit higher up the chain, you have Cubase SE (PC & Mac), and Sonar Studio (PC), Logic Audio big box (Mac) or the self-contained Reason (PC & Mac).
If you want to go beyond synth presets, soundfonts and GM sounds, then you'll probably want to understand analog (subtractive) synthesis - see Analog Synthesis for Beginners for an introduction.
The "definitive site" for this is KvR-VST. Go there and read a bit, then sign up to ask questions. It's a friendly crowd. Just don't go here, that guy isn't very helpful.
By now everyone should have heard about Dick Cheney and his loud put-downs. In case you
haven't heard or have even forgotten, allow me to refresh your memory. To begin at the
beginning...
I see we have a new Bulwer-Lytton competitor in the making.
If this is a BIG IBM mainframe then it will take more floor space than a single rack of twin processor CPUs.
We have a 9672-R42 (75 or so MIPS, runs OS/390, VM/ESA, and Linux/390 under VM) and it is about the size of a large refrigerator. The ESS (enterprise storage server) is about the size of a small commercial freezer, or 2 large refrigerators, for 840GB (and room to expand).
I assume that VM programmers are in short enough supply that paying one $90k p.a. is reasonable. It's not far from what I get paid as a Unix SA.
Depends on location and industry, but I'd agree in general. VM systems programmer are not as common or as in-demand at the moment. I am a VM system programmer, cross-trained on Unix (primarily AIX and Solaris, but also Linux-and OS/390 literate - at state universities people tend to wear a lot of hats). Another person is assigned to the Linux/390 responsibilities.
Be aware, however, that IBM's newest Linux/390 solutions don't require VM in order to operate. That cuts a big chunk out - both staff and costs.
And the hardware is WAY more expensive.
Depends on how much scalability you need. A Multiprise 3000 can go smaller than the 9672 series (physically and capacity), but still, it's not something you need to support just 500 users.
Having said that, we are moving away from the Linux/390 solution to an Linux under Intel, because we are phasing out VM and moving to a smaller processor to support OS/390 only.
A "Susan Richards" from Harris Publishing called me not too long ago, offering to place me in the Oak Hill High School alumni directory. That high school isn't local to this area, nor did I attend it. I saw it was "out of area" so I didn't answer it, bhey left a message on my answering machine, with an 800-546-2533 number to return the call.
When I returned the call, I found the person at the other end was rather accustomed to offended people calling back: - they knew that since nothing was being sold it was not an "illegal" telemarketing call - they were well-trained to keep a calm demeanor in the face of an obviously irate client
But, venting for a few minutes got it off my chest, and it was on their nickel.
Slashdot Mirror
You got that right... for years we had a VS1-MVS-XA-ESA-OS/390-z/OS environment with a parallel VM/370-VM/SP-VM/ESA environment for doing development. Our change control was simple, our sources were based on 80-byte records, etc. Our online environments were CICS and a few home-grown DMS/CMS applications, batch was predominantly PL/I with ISAM (and later VSAM) files. Then we brought in a DBMS with a 4GL and built-in TP monitor. (Model 204). Life was still pretty good, although we started writing REXX applications and had to develop change control for that and the DMS/CMS code.
Eventually CMS went away - the programmers moved to TSO, the functional users (SCT Banner's term for "end users" or "lusers") moved to a combination of TSO/ISPF, Model204 applications, and web apps. But our mainframe change control processes still worked.
Enter Unix, in the guise of SCT Banner. Don't let anyone kid you, it's an ERP, and a big hairy mess. Many of our programmers are "back to square 1", having to deal with C, shell scripts, perl, etc rather than JCL, PL/I and User Language. Cobol is somewhat familiar ground, although "make" is a wierd construct to them and shell script drivers are copied by rote (they're used to DMS/CMS or ISPF applications building compile JCL).
Change control? Hah. We're so busy trying to get acclimated to the environment that the closest we have right now is ".old" and ".save" files laying around. I've installed SVN, but I'm too busy fighting fires to write the documentation, particularly since I'm one of the few people that truly *is* Unix-literate (but I can still build a CP nucleus if I had to!) I spent 2.5 hours tonight unsnarling Banner Job Submission and its interaction with Appworx.
Doug
Lately I've been buying music software and hardware, and http://www.bizrate.com/ has been good for me.
Twice recently I took quotes I got off of Bizrate into Guitar Center and they were willing to beat the price - but if not I had a decent deal available over the net - most recently I got a Presonus Firebox firewire audio interface for my laptop.
Doug
I remember Relay.
I used to support a usenet news server written in REXX (PSU NetNews), and had IRC, mail (Shaffer Mail), NNTP newsreader (NNR) and web browser (Charlotte) clients, all written in REXX.
There was also VM Gopher client and server, and I (just for fun) briefly ran a VM HTTPD written in REXX.
Doug
For those wondering why the mandatory comment, it was not a requirement to force documentation into a program (-:
EXEC, EXEC2, and REXX scripts shared the same common filetype (extension), "EXEC".
When the command processor went to execute an exec program, it looked at the first line. First lines beginning with a REXX comment were passed to the REXX interpreter. First lines beginning with the token &TRACE were passed to the EXEC2 interpreter. Otherwise they were passed to the original EXEC interpreter.
BTW, for the guy asking about the acronyms:
VM/ESA (and VM/370 and VM/SP) were virtual memory operating systems (not unlike VMware) that allowed "bare metal" operating systems to share a single processor. VM would run underneath itself (very common when working on upgrades), and it was also used to support DOS/VSE, UTS (Amdahl's mainframe Unix), VS/1, and MVS variants.
CMS (Conversational Monitoring System) was the interactive environment that most users had to edit, print, compile, and execute programs. In addition, our MVS guest machines generally IPL'd (booted) CMS to do some setup, and the last line of their profile exec (autoexec.bat-like) was to boot the device that contained MVS.
z/OS (and forerunners OS/390, MVS/ESA, MVS/XA, MVS/SP, MVS and VS1) is essentially batch operating systems (not the best description really), but a batch job or started task (daemon) can run multiple-user TP monitors like TSO and CICS that allow people to interact over 3270 (block-mode) terminals and other connections. Database services under MVS included DB2, IMB, Model 204, IDMS (who remembers that one?) and others.
ISPF is the Interactive System Productivity Facility, a menu/panel/picklist/editor environment with file tailoring (template) processing. It's common in the TSO (Time-Sharing Option) environment, less so in VM. DMS/CMS was a CMS-only panel manager that had a lot less baggage than ISPF.
CUFS was College and University Financial System, an accounting package for higher ed. It was rolled into Advantage by the vendor, AMS, during the run-up to Y2K.
SCT is the vendor of Banner, essentially an ERP for colleges and vendors. It is very dependent on Oracle facilities (database, application server, and other services). My thoughts about the product are "not kind", mostly due to documentation and implementation schedule issues.
Got all that?
Doug
Whoa, another Model204 user!
We (YSU - Youngstown State) installed 8.0 in January 1985. Initially we ran M204 under VM because our VS/1 system didn't have enough space for online M204 systems. That cleared up once we went to MVS/XA. We were a beta site for several releases, had site visits from Mary T & Alan Y.
Model204 under CMS has some nice interface features to REXX, although we never used it.
Alas, due to Banner, Model204 at our site is going the way of our VM & REXX code, but we'll have it for a few more years yet. M204-L has had recent discussion about "Another one bites the dust", but I haven't mentioned what we're doing yet.
Doug
I used to be the VM/ESA systems programmer (king geek) for a state university (I'm still at that university, it's been over 21 years).
REXX was the first serious scripting language that IBM delivered for VM (EXEC was awful and EXEC2 not much better). Our systems development (applications) staff wrote quite a number of in-house REXX applications interfaced to DMS/CMS (this was before ISPF was very usable under VM). Most of these were working with CUFS (later Advantage). I used REXX extensively to match-merge two files, generate reports, and reformat data. I also rewrote some programs in REXX that had originally been implemented in SNOBAT (a snobol4 dialect for System/370).
Roll forward a few years. All the sudden, I'm responsible for Unix servers as well as VM. Although I installed regina on our Unix servers, I figured out pretty quickly that perl was the preferred script language for Unix (I first installed 4.0.36). I saw that there were a lot of facilities and working scripts in perl that I'd have to build for myself in REXX, so I made a point to learn perl. I still used REXX for things that interacted with our VM/ESA and z/OS & TSO/ISPF environment.
Roll forward a few more years. IBM drops HESC, and VM becomes prohibitively expensive to keep. Meanwhile, our academia is moving to Unix and PC-based teaching, and a Unix-based ERP is on the horizon. We decided to eliminate VM. I spent quite a few hours writing perl scripts to parse DMS/CMS panel sources and REXX programs, to build ISPF panels and generate ISPF-friendly REXX from the DMS/CMS REXX code (fortunately most of the code was cookie-cutter so it was easy to do a find/replace). I knew these programs would be eliminated when the ERP was in place.
Now I'm so neck-deep in Oracle (database, application server, and other toys) and SCT Banner that I maybe spend 10 minutes a day on our z/OS system, and haven't written a new program there (in any language, much less REXX) in six months. I still maintain or help debug a REXX program now-and-then.
REXX was a success, but for us VM died. I still like REXX, but perl has pretty-well replaced it for me. The last time I wrote a REXX program I caught myself writing perl-isms into it that I had to fix.
Doug
We've had external auditors come through with their "best practice checklists" and ask us all kinds of questions, then they make their report to the ones that brought them in.
Two years ago, after the report went to the Board of Trustees (I work for a state university), we were tasked to give a "when or why not" to each and every issue on the report.
On the bright side, the particular auditor we've had to deal with most of these times was as fair and accurate as can be expected - there were no real surprises sprung on us (she's back next week to do our Oracle systems).
Doug
If I remember right, a couple of years ago Intuit removed the ability of QuickBooks to talk to any SMTP server but theirs - and you had to open an account with them for a monthly fee in order to send e-mailed invoices or bills through their server.
Then the Turbo-Tax/macrovision mess... now this...
I tried Quicken once, it was more hassle than it was worth. I do my bills over the internet via CheckFree, and I use HR Block Taxcut for my income tax.
Doug
I've had opportunities to upgrade my skill set at the university's expense over the years.I started out as a systems programmer for VM/SP and VS/1, through a 3270-based database (Model 204) and VM/ESA and REXX applications, and now I'm a Unix system admin with some Oracle DBA responsibilities, as well as auxilliary products like Tivoli Storage Manager and using lots of open source products like Apache, Exim, and perl.
We have an entire staff (both technical/development staff and functional staff) presently retraining from the 3270 world to SCT Banner, an ERP package based on Oracle DBMS, Application Server, etc. In addition, we've recently hired for our Tech Desk, and some functional areas have their own tech people as well.
It's worth a look at any rate.
Doug
I'll probably regret saying this but the future of digital recording/editing will not use one computer. In the future you might use your laptop to run the software and have 2-3 computers networked in a different room running plugins and othe3r audio processes.,
No one really wants to work that way right now -- most audio professionals I know really dont understand the power behind distributed networking.
It's not big yet, but it's already happening... on KVR I've read of guys using a Mac to control two or three PC's running Gigastudio (PC-only), people using VST System Link, FX Teleport, DMIDI, MIDI-over-LAN or just plain MIDI cables to link two or more PC's, etc.
Makes my setup (PSR-2000 with floppy drive, 2ghz pentium 4 and 1ghz laptop with appropriate sound cards and networked)seem pretty primitive by comparison.
Doug
Assuming you're on the Windows platform, I would suggest you check out FLStudio - it comes with some decent software synths (FLS calls them "generators") and also host many free virtual instruments ("vsti" and "dxi"), as well as shareware and commercial ones.
There are other choices as well - Orion (PC), Muzys (PC & Mac), Cubasis VST (PC & Mac) Tracktion (PC, Mac in beta), Massiva (PC), and Cakewalk Home Studio 2004 (PC) for example. A bit higher up the chain, you have Cubase SE (PC & Mac), and Sonar Studio (PC), Logic Audio big box (Mac) or the self-contained Reason (PC & Mac).
If you want to go beyond synth presets, soundfonts and GM sounds, then you'll probably want to understand analog (subtractive) synthesis - see Analog Synthesis for Beginners for an introduction.
The "definitive site" for this is KvR-VST. Go there and read a bit, then sign up to ask questions. It's a friendly crowd. Just don't go here, that guy isn't very helpful.
Doug
DO a web search for BSODPROP - I had this on a W98SE box that made the screen black with red letters, sorta-like Halloween.
Alas, it reportedly doesn't work with newer OS's.
Doug
I see we have a new Bulwer-Lytton competitor in the making.
Doug
Yes! I loved TIM. Mouse motors, toasters, and laundry baskets to solve problems. Return of The Incredible Machine - Windows and Mac. Doug
Be aware, however, that IBM's newest Linux/390 solutions don't require VM in order to operate. That cuts a big chunk out - both staff and costs.
Depends on how much scalability you need. A Multiprise 3000 can go smaller than the 9672 series (physically and capacity), but still, it's not something you need to support just 500 users.Having said that, we are moving away from the Linux/390 solution to an Linux under Intel, because we are phasing out VM and moving to a smaller processor to support OS/390 only.
Doug
A "Susan Richards" from Harris Publishing called me not too long ago, offering to place me in the Oak Hill High School alumni directory. That high school isn't local to this area, nor did I attend it. I saw it was "out of area" so I didn't answer it, bhey left a message on my answering machine, with an 800-546-2533 number to return the call.
When I returned the call, I found the person at the other end was rather accustomed to offended people calling back:
- they knew that since nothing was being sold it was not an "illegal" telemarketing call
- they were well-trained to keep a calm demeanor in the face of an obviously irate client
But, venting for a few minutes got it off my chest, and it was on their nickel.
Doug