jeffb@blia.BLI.COM (Jeff Beard) (11/08/90)
The brief answer is, 'Rent time from a time-sharing service' unless you enjoy systems programming and operational make-work. You will consume significant resources (time, $$$, people, floor space) supporting your own system, especially IBM mainframes! If you're limited in such resources, and who isn't, this is the ONLY way to go. If however, you estimate multiple concurrent projects, long-lived projects with many releases, time-sharing CAN soon justify hardware and software expenditures for a mainframe ... but just WHICH? By assumption (2) below, you will need to justify 9370 4381 308x 3090 For ALMOST all mainframe support, the 4381 is a good choice. THE REAL ISSUES UNDERLYING THIS QUESTION ---------------------------------------- The final equivocator of developing SW in one environment and porting it to another, is the systems level QA test. Assuming implementation is in a language that is 'portable' ala C, Pascal, ADA, ... , the effectiveness (economic and technical) depends upon a thorough understanding of : 1) the language itself 2) the target hardware/software system requirements Having worked on such projects for over six years now, my experience leads to the conclusion that this is an effective means to deliver SW. If the workstation environment can be used to develop AND debug the system PRIOR to porting, then the QA and porting problems land on assumption (2) above. The usual traps are calling target system specific interfaces and/or coding some routines in low-level assembler. In my last major project, development and debugging was performed on Sun workstations targeting for BOTH IBM/VM and MVS systems. As the implementation language was C, and the 370 SAS/C compiler generates compatible *.o (text decks) [the justification for choice], the scope of effort / cost was (subjectively) Sun VM MVS 100 -> 10 -> 1 This is ignoring the often non-trivial issue of setting up the target environment ( specifically MVS!). The transition from Sun->VM exposes the major System/370 problems and the final VM->MVS SHOULD be totally dependent upon MVS specifics, else you've got a design flaw. Jeff Beard jeffb@blia.UUCP Teradata, Los Gatos, CA Opinions expressed above are just that :- personal opinions