Re: Slushware
On Fri, 26 Dec 2014 05:55:57 -0600, Shane Ginnane wrote:
I sometimes wonder when was the last time anyone installed to a real piece
of hardware - no {pico,micro,macro)-code.
Slushware is ubiquitous.
The corollary of course is how do vendors like vmware and IBM convince
customers for continue to pay for hipervisors ?.
z/OS is not the only golden goose apparently.
It began nearly a half century ago with microcode implementation of S360
models, and only slightly later, W. M. Waite's Mobile Programming System.
Nowadays:
microcode-millicode-PR/SM-VM-JVM-byte code
How many layers have I neglected? Hercules is a confluent branch.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
On Thu, 25 Dec 2014 22:29:07 +, Blaicher, Christopher Y. wrote: BSAM gets the length of the block to write from the DCB BLKSIZE at the time of the WRITE. As long as the DCB BLKSIZE is equal to or less than the max BLKSIZE all is OK. BSAM will build the CCHHRKDD from the various values it keeps and the DD comes from the BLKSIZE. I guess you could always leave the BLKSIZE in the DCB, but you are supposed to set the BLKSIZE to the BDW size. I have not done much with BSAM in years, mostly EXCP and STARTIO, so myknowledge of what BSAM checks and validates is vague at best. IIRC, for RECFM=V(B)(S) I never modified DCBBLKSI. I, likewise, and my Assembler skill has atrophied in the decades. For RECFM=FB, a short block is fine as long as it is a multiple of LRECL. As for finding end of file, it is recognized by the EOF marker or end of the last extent, if blocks so fill a track that the system can't fit an EOF marker on it. I remember that to write a short FB block I modified DCBBLKSI, and if I neglected to restore the earlier value before CLOSE Bad Things happened. IIRC, for RECFM=V(B)(S) I never modified DCBBLKSI. Now for Mr. Altmark's comment. Yes, using BSAM, MVS can write all RECFM=VB blocks BLKSIZE in length, but I would not guarantee that everybody will accept them as valid. Also, you would be wasting a lot of space on tracks if you do that. Bottom line - Write well-formed blocks and follow the rules as outlined in the various DFSMS manuals. I'd welcome a specific citation. On 2014-12-22, at 10:13, Alan Altmark wrote: ... MVS has no problem with short records in a block for VB[S] files. Padding the last record doesn't hurt because MVS writes ECKD records that are BLKSIZE in length, but you must not modify the RDW to include the pad bytes. Or, for RECFM=V(B)S you may use Null Segments for padding. Two respectable experts disagree. I remember that for RECFM=V(B)(S) I merely put the desired length in the BDW. I don't yet know which: o Does BSAM write BDW bytes? o Does BSAM always WRITE DCBBLKSI bytes and QSAM ignore the excess on GET? My experience (above) seems to support this. o Does Postel's Principle pertain? Certainly for RECFM=V, always writing BLKSIZE bytes would be wasteful for a ragged file (a preponderance of short records). It's a pity that QSAM doesn't routinely exploit track balances. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
Paul Gilmartin wrote: It began nearly a half century ago with microcode implementation of S360 models, and only slightly later, W. M. Waite's Mobile Programming System. Nowadays: microcode-millicode-PR/SM-VM-JVM-byte code How many layers have I neglected? Hercules is a confluent branch This is fun. I'm not sure modern machines are both microcoded AND millicoded-I thought millicode was just another form of microcode. Am I wrong? To make it more exciting, how about this perversion (I'm removing microcode just in case): millicode==PR/SM==z/VM==Linux==Bochs==Windows That's one more than your layering (whether microcode still exists or not)! Now, will it be speedy? I think not... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes: It began nearly a half century ago with microcode implementation of S360 models, and only slightly later, W. M. Waite's Mobile Programming System. Nowadays: microcode-millicode-PR/SM-VM-JVM-byte code How many layers have I neglected? Hercules is a confluent branch. note that the original hypervisor was done by Amdahl in something called macrocode ... which was a layer above microcode and very close to standard 370. In the mid-70s, I had been sucked in by Endicott to help with microcode assists for 138/148 ... vertical microcode machine that avg. 10 microcode instructions per 370 instruction (not that different from the various intel based simulators). Was told that there were 6kbytes available for microcode and kernel instruction sequences dropped into microcode on nearly byte for byte ... so was to identify the top 6kbytes worth of kernel instruction sequences ... that would be moved to microcode for a 10:1 performance improvement. Old post with results of analysis ... turns out top 6kbytes of instruction sequences accounted for 79.55percent of kernel time. http://www.garlic.com/~lynn/94.html#21 In any case, I was giving presentations on the effort at the monthly bay area user group meetings (BAYBUNCH) held at SLAC ... and the Amdahl people were pumping me for additional details at the get togethers held at local watering holes after the meetings (this was before hypervisor was announced). After hypervisor was announced ... the 3090 was eventually forced to respond with PR/SM. Part of the issue was that 3090 was horizontal microcode machine ... which was enormously more difficult to program for than 370 instructions ... and was much more difficult. I had been told that Amdahl had original evolved macrocode to respond to the enormous number of architecture tweaks that IBM had been doing on their high-end (vertical microcode machines) starting with the 3033 and continued through 3081 (macrocode used to drastically reduce the effort needed to respond). I've mentioned before ... during FS period ... internal politics were killing off 370 efforts (the lack of 370 products during this period is credited with giving clone processor makers a market foothold) ... then when FS imploded there was mad rush to get 370 products back into pipeline. POK kicked off 3033 (initially 168 logic remapped to 20% faster chips) and 3081 in parallel ... more detailed account here: http://www.jfsowa.com/computer/memo125.htm since that neither 3033 or 3081 were really that competitive, the architecture tweaks would supposedly give the machines competitive advantage ... many were claimed to be performance improvements ... but folklore is that many actually ran slower (than native 370). Part of the issue is the high-end, horizontal microcode machines were profiled in terms of avg. machine cycles per 370 instruction ... by 3033, this was done to cloe to one machine cycle per 370 instruction (370 instruction move to microcode couldn't see the 10:1 improvement seen on the vertical microcode machines). In anycase, it sort of drove Amdahl into creating macrocode as a way of drastically simplifying being able to respond to the increased architecture tweaking. The other factor was that part of the mad rush after FS failure, the head of POK managed to convince corporate to kill off vm370, shutdown the development group and move all the people to POK ... or otherwise POK would be able to make mvs/xa ship schedule several years (Endicott managed to save the vm370 product mission, but had to reconstitute a development group from scratch). Part of the POK activity was creating a XA vritual machine VMTOOL (to support MVS/XA development) that was never intended to be made available to customers. After initial introduction of 370/xa and MVS/XA ... there was very slow uptake ... customers continued to run 3081s in 370 mode with MVS (or vm370). The decision then was to release the VMTOOL as the migration aid ... allowing customers to run both MVS and MVS/XA concurrently on the same machine as aid to migration. Amdahl solution was the hypervisor which provided the same capability ... but much more efficiently. IBM eventually responded with PR/SM on the 3090 ... but it was much greater effort because it required being all done in native horizontal microcode. The POK(/Kingston) group then pushed very hard to have migration aid morph into standard VM/XA product. The problem was that VMTOOL had only been developed for MVS/XA development and lacked lots of function and performance features (especially compared to vm370 of the period) and was going to require lots of resources, effort and time to bring up to compareable level of vm370. Somebody at an internal datacenter had made the changes to vm370 to provide full function 370/XA support ... which would have been trivial to release. In the internal politics between POK and Endicott, POK managed to prevail and
AW: Re: AW: //STARTING JOB ...
You probably mean //STARTING EXEC ... not //STARTING JOB, do you? I am on vacation right now and cannot test. I know that two lines are inserted, one of them is a JOB card, the other an EXEC statement. Nothing gets inserted. Try to think about it from another point of view: You want to submit a job. One way to do it is by starting an ISPF EDIT session, then write the JCL for your job, and finally issue submit. If you let aside that submit can generate a job statement for you, the minimum JCL you need to write is a JOB and an EXEC statement. This is what the START command used to do before Started Job support was introduced with MVE/ESA 5.2 (I believe). START built a JOB and an EXEC statement to invoke the JCL procedure specified on the start command. This job was then processed by either the master or primary (or any other) subsystem. As of MVS/ESA 5.2 START will do some processing *before* the step described above: It looks if the member specified is found in one of its JCL library concatenations (IEFJOBS, IEFPDSI), and if found, if this is a JCL starting with a JOB statement. If the first statement is *not* a JOB statement, START reverts back to the processing describe above. However, if it *is* a JOB statement, the content of this very member is then read and handed over to the master or primary (or any other) subsystem. In either case, the subsystem is not adding to nor modifying the JCL received. There is nothing you can do to change this behaviour, I knew of. These are just the rules. Place your Started Jobs JCL in one of the libraries in the IEFJOBS or IEFPDSI concatenations. This is the only place JOBs are accepted, even it they are to run under the primary JES. There is nothing that forbids a JCL (procedure) library to be in the IEFJOBS, the IEFPDSI as well as in one or more JES PROC concatenations. I tried to describe that jobs are supported only if they are present in either IEFJOBS or IEFPDSI of MSTJCLxx. This is true even if the job is to be started under a JES. The START command processor reads the JCL from IEFJOBS or IEFPDSI and submits it. That is not quite true. Once the JCL already containing a JOB statement is not contained in MSTJCLxx (only in the JES2 proclib concatenation), the automatic insertion of these two lines (by whatever) causes a JCL error. Yes, it is true. The case you describe is *not* supported. Full stop. No, as I wrote, it is the START command processor that builds these two statements. It is my understanding that the way those statements are build is not different whether they're gonna be sent to the MSTR or to a JESx subsystem. Implicit in any START command is 'SUB=JESx' (that's the default). Exception is if the MEMBER name is equal to an existing subsystem. In that case, the default in the start command is SUB=MSTR. My start command is ALWAYS issued with implicit SUB=JES2. Behaviour is different if the JCL is NOT contained in MSTJCL, only in JES2 proclib. Well, yes I can agree that the behaviour is different in the case you describe: It the behaviour of a supported versus an unsupported case. Why don't you simply add the membet ot a library already in IEFJOBS or IEFPDSI concatenation? Alternatively, add that library to one of these concatenations. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDW length vs. Physical Length
At 10:49 -0600 on 12/27/2014, Paul Gilmartin wrote about Re: BDW length vs. Physical Length: It's a pity that QSAM doesn't routinely exploit track balances. I agree. It is a waste of track space when the access method refuses to write short blocks just to keep all but the last block as BLKSIZ long. I think that VB(S) is might actually make use of the gas at the end of a track and output a short block/segment to fit. It seems to be a trade-off between I/O efficiency/processing and use of the space on a track. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: //STARTING JOB ... was: Re: JCLLIB in started proc?
Seriously, no one cited security as a why for this restriction. Part of a proper system setup anc change management is to limit who can use the START command, possibly what he/she can START and for sure who can apply changes to JCL the JCL (procedure) libraries in discussion. If this JCL could be modified by content of personal libryries, this would undermine the above. What hinders you to ask for the JCL (procedure) library to be added to IEFPDSI? Ask for it, expain your case. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes: How many layers have I neglected? Hercules is a confluent branch. re: http://www.garlic.com/~lynn/2014m.html#161 Slushware http://www.garlic.com/~lynn/2014m.html#163 Slushware for other hercules drift ... risc processors had performance advantage over intel ... risc having made extensive use of technolology to compensate for the increasing mismatch between memory latency and processor speed ... out-of-order execution, speculative execution, branch-prediction, etc ... sort of the hardware equivalent of '60s multiprogramming to keep processor busy while waiting for disk access (current memory latency, measured in count of cpu cycles is compareable to 60s disk latency when measured in number of 60s cpu cycles). however, for nearly 20yrs, intel has gone to hardware layer that translates intel instructions into risc micro-ops for execution ... largely negating any risc performance advantage. note that somewhat similar (out-of-order, etc) technology started to be introduced for z196 ... claiming it provided over half the performance improvement from z10 to z196 ... and further additions responsible for some of the z196 to ec12 performance improvement. another technology (compensating for stalled instructions) is hyperthreading. I first ran into it when I was asked to help 370/195 for a hyperthreading implementation they wanted to do. 370/195 had pipeline supporting out-of-order execution that could run at 10mips ... but didn't have branch prediction ... so conditional branches would stall the pipeline ... many codes only ran at 5mips. The idea was to simulate multiprocessor operation with two instruction streams, registers ... but still the same pipeline and execution units (two 5mip instruction steams keeping the 10mip execution units busy). note that it dates back to acs/360 in the late 60s ... see multithreading reference near the end of this article http://people.cs.clemson.edu/~mark/acs_end.html also referenced here http://en.wikipedia.org/wiki/Simultaneous_multithreading SPARC T5 can have 8chips/system, 16cores/chip and 128threads/chip (aka 8threads/core) http://en.wikipedia.org/wiki/SPARC_T5 by comparison, about same time as ec12, e5-2600v1 had two 8core chips for 16cores total and 400-600+ BIPS rating (depending on model) ... compared to max configured (101 processors) EC12 @75BIPS. both e5-2600v1 and ec12 processor chips are done in 32nm technology. intel has a tick-tock chip generation http://en.wikipedia.org/wiki/Intel_Tick-Tock alternates shrinking previous chip design with new technology (tick, e5-2600v2 22nm tech) and then designing new chip for the new technology (tock, e5-2600v3 redesign 22nm). some e5-2600v3 ( v4) discussion http://techgadgetnews.com/2014/09/21/intel-xeon-e5-2600-v3-haswell-ep-workstation-and-server-processors-unleashed-for-high-performance-computing/ E5-2690v1 at 632BIPS, E5-2690v2 at 790BIPS, E5-2690v3 at 996BIPS, E5-2699v3 at 1.321TIPS. http://www.tomshardware.com/reviews/intel-xeon-e5-2600-v3-haswell-ep,3932-7.html note MIPS/BIPS/TIPS are benchmark iterations compared to 370/158 assumed to be 1MIP processor. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
On Sat, 27 Dec 2014 09:17:20 -0800, Phil Smith p...@voltage.com wrote: This is fun. I'm not sure modern machines are both microcoded AND millicoded-I thought millicode was just another form of microcode. Am I wrong? Sure. Millicode sits between your program and the machine's native instruction set. It is part of the firmware, meaning it can be changed. It primarily intercepts any non-native instruction and breaks it down into a sequence of native instructions or redirects that data to another processor. Microcode is burned into the CPUs, being the on-chip logic that actually runs the native instruction set. In rare cases millicode may intercept a native instruction and re-implement it, such as might be done if an error is found in microcode or chip design too late or too expensive to fix. A z/Architecture instruction may shift from millicode to native and back several times over its life as the underlying chip design changes. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
