peter.far...@broadridge.com (Farley, Peter x23353) writes: > IIRC there is no easy FTP in or out of VM/370. Your only real > transfer capability is the VM/370 system reader and punch. The VMARC > format (like XMIT) packages text in 80-byte records and can be > transmitted back and forth using reader and punch. There are both MVS > 3.8 and VM/370 versions of VMARC, so files created in MVS 3.8 can be > transmitted back and forth with VM/370. There is also a VM/370 dump > command which writes files to the punch, but I forget the output > format that it uses.
re: http://www.garlic.com/~lynn/2011m.html#30 CMS load module format ... note lots of os/360 (&/or mvs) applications/compilers were ported to CMS .... by implementing simulation of os/360 access method services (on cms filesystem, this is different from simulation of os/360 access method services on real mvs disks mentioned below). CMSSEG was introduced in vm370 release 3 with DCSS (a very small subset of my paged-mapped filesystem and virtual memory management changes mentioned below). OS simulation should be in CMSSEG (there was joke about 32kbyte OS/360 simulation code in CMSSEG was much more cost effective OS/360 simulation than the 8mbyte OS/360 simulation in MVS). this has discussion about standard hercules distribution and whether cmsseg definition is in conflict with the cms virtual machine size you are using: http://osdir.com/ml/emulators.hercules390.vm/2003-11/msg00132.html "disk dump/load" was one of the original cms (when it was cambridge monitor system on cp67 ... before morph to vm370 and name change to conversational monitor system) commands from mid-60s. The original CMS filesystem formated disks into 800-byte fixed length physical records (early form of FBA). a similar gimick (temporary changing file format to 800-byte fixed-length records) was also used by the cms tape dump/load application ... but physical 800-byte blocks on tape. from dmsdsk (also from vm370 release 6) * DUMP: DISK COPIES THE FILE DESIGNATION FROM THE 00096000 * PARAMETER LIST INTO BYTES 58 - 76 OF AN 89-BYTE 00097000 * BUFFER. (THE FIRST FOUR BYTES OF THE BUFFER CONTAIN 00098000 * AN IDENTIFIER CONSISTING OF AN INTERNAL 00099000 * REPRESENTATION OF A 12-2-9 PUNCH AND THE CHARACTERS 00100000 * 'CMS'.) THEN DISK TEMPORARILY CHANGES THE 00101000 * CHARACTERISTICS OF THE FILE IN THE 40-BYTE FST ENTRY 00102000 * TO MAKE IT APPEAR AS A FILE OF 800-BYTE FIXED-LENGTH 00103000 * RECORDS. (THE CORRECT FST ENTRY IS RESTORED WHEN THE 00104000 * FILE HAS BEEN DUMPED, OF COURSE.) DISK MOVES THE 00105000 * INITIAL VALUE FOR SEQUENCING 00106000 * (001) INTO BYTES 77-80 OF THE BUFFER. DISK NEXT 00107000 * CALLS THE DMSBRD FUNCTION 00108000 * PROGRAM TO READ THE FIRST 50 BYTES OF THE TEMPORARY 00109000 * COPY INTO 00110000 * BYTES 6-55 OF THE BUFFER AND THEN THE DMSCIO FUNCTION 00111000 * PROGRAM TO PUNCH 00112000 * THE CONTENTS OF THE BUFFER. HAVING PUNCHED THE FIRST 00113000 * CARD, DISK INCREMENTS THE SEQUENCE NUMBER (BYTES 00114000 * 77-80 OF THE OUTPUT BUFFER) AND OVERLAYS BYTES 6-55 00115000 * OF THE BUFFER WITH THE NEXT 50 BYTES OF THE FILE 00116000 * BY CALLING DMSBRD. IT THEN PUNCHES THE CONTENTS OF 00117000 * THE 00118000 * BUFFER. DISK REPEATS THIS PROCESS FOR EACH 00119000 * SUBSEQUENT 50 BYTES OF DATA IN THE TEMPORARY DISK 00120000 * FILE. WHEN THE END-OF-FILE IS ENCOUNTERED, DISK 00121000 * GENERATES AN END CARD (ONE WITH N IN COLUMN 5) AND 00122000 * PUNCHES IT, 00123000 * CALLS THE CP CLOSE COMMAND TO CLOSE PUNCH 00124000 ... snip ... During the FS period ... some past posts http://www.garlic.com/~lynn/submain.html#futuresys lots of 370 development (both software & hardware) was cut back all over the company. with the failure of FS ... there was mad rush to get stuff back into the 370 product pipelines. This was motivation for picking up a lot of 370 stuff I had been doing all during the FS period for vm370 release 3 ... some old email related to converting & enhancing bunch of stuff from cp67 to vm370: http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 and then additional stuff as separate kernel add-on (used as guinea pig for starting to charge for kernel software) ... http://www.garlic.com/~lynn/subtopic.html#fairshare http://www.garlic.com/~lynn/subtopic.html#clock MVS was in mad rush to do mvs/xa ... which was going to take another 7-8 years ... but the head of POK managed to convinced corporate to kill-off the vm370 product, close the development group, and transfer all the people to POK or otherwise MVS/XA wouldn't be able to make it ship date. While this was going on, somebody in the vm370 development group had done a fairly full set of CMS OS simulation access method for operating against real MVS formated disks. however, releasing this code was not consistent with the decision to kill off vm370 product (which would have gone out prior to vm370 release 6 ... and would therefor could have been part of the source base). There is joke that head of POK was one of the biggest contributor to DEC VAX/VMS ... since so many development people left and went to work on DEC's (infant) VMS, instead of moving to POK (including individuals responsible for the significantly enhanced OS simulated access methods). In the resulting chaos ... the source for that implementation disappeared. Eventually, Endicott managed to "save" the vm370 product mission, but had to reconstitute a development group from scratch. VMFPLC was done as an enhanced TAPE dump/load ... but with larger tape block sizes. I borrowed source for VMFPLC (wasn't part of standard distribution) to make the changes necessary to support my cms virtual memory mapped filesystem ... some past posts http://www.garlic.com/~lynn/submain.html#mmap I was then asked to provide Endicott a copy of the source ... since it was another thing that got lost in the chaos of shutdown of the vm370 development group. http://www.garlic.com/~lynn/2006t.html#24 CMSBACK above also mentions CMSBACK ... which I had done in the late 70s for internal datacenters ... I had made further enhancements to vmfplc to use as backup/archive. misc. old email mentioning cmsback http://www.garlic.com/~lynn/lhwemail.html#cmsback CMSBACK later morphs into workstation datasave (as customer product), then ADSM and finally as current TSM. misc. past posts mentioning backup/archive http://www.garlic.com/~lynn/submain.html#backup other old posts mentioning vmfplc http://www.garlic.com/~lynn/99.html#149 OS/360 (and descendents) VM system? http://www.garlic.com/~lynn/2001n.html#92 "blocking factors" (Was: Tapes) http://www.garlic.com/~lynn/2002h.html#35 Computers in Science Fiction http://www.garlic.com/~lynn/2002h.html#36 Computers in Science Fiction http://www.garlic.com/~lynn/2003b.html#42 VMFPLC2 tape format http://www.garlic.com/~lynn/2003b.html#43 VMFPLC2 tape format http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post) http://www.garlic.com/~lynn/2003k.html#47 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage http://www.garlic.com/~lynn/2004e.html#39 Candle support from Los Delhi http://www.garlic.com/~lynn/2005j.html#56 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP http://www.garlic.com/~lynn/2005p.html#42 VMFPLC2 to load EREP PTFs http://www.garlic.com/~lynn/2006.html#8 How to restore VMFPLC dumped files on z/VM V5.1 http://www.garlic.com/~lynn/2006.html#9 How to restore VMFPLC dumped files on z/VM V5.1 http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1 http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC http://www.garlic.com/~lynn/2008j.html#72 tape blocking http://www.garlic.com/~lynn/2009.html#17 Magnetic tape storage http://www.garlic.com/~lynn/2009n.html#66 Evolution of Floating Point http://www.garlic.com/~lynn/2010l.html#19 Old EMAIL Index -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
