Re: DOS descendant still lives was Re: slight reprieve on the z.

t...@vse2pdf.com (Tony Thigpen) writes: > The 4300 did not come out of Endicott. It was developed in Germany, in > the same lab that developes DOS/VSE. As an undergraduate I do lots of work on cp67 (including to run in 256kbyte machine). The morph of cp67 to vm370, did a lot of simplification of

Re: DOS descendant still lives was Re: slight reprieve on the z.

other trivia in the wake of FS and mad rush ... 303x was kicked off ... as mentioned 3033 was 168 logic remapped to 20% faster chips ... that happened to have ten times more circuits per chip. Using original 168 logic, 3033 would have been only 20% faster than 168 (aka 3.6mips). However, some

Re: DOS descendant still lives was Re: slight reprieve on the z.

In <87egefr5wr@garlic.com>, on 12/21/2015 at 10:52 AM, Anne & Lynn Wheeler said: >It showed 4341 was faster than 158&3031 Doesn't that depend on whether your benchmark is packed decimal or gloating poin arithmetic? -- Shmuel (Seymour J.) Metz, SysProg and JOAT

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

I'm talking from experience. The two hours-long CEC failures we had--most recently in the fall of 2014--took down all CICS and DB2 applications as well as three ICFs on the box that failed. The secondary 'penalty' box stayed up and kept live copies of structures so that after hardware repair,

Re: managing /tmp

Here are some notes in the appendix of our quick-guide for setting up IBM Ported Tools OpenSSH that mention "Best practices" for managing /tmp space. Any ideas or suggestions for improvement are appreciated. http://dovetail.com/docs/pt-quick-inst/pto-inst-tmp.html Kirk Wolf Dovetailed

Re: managing /tmp

On Mon, Dec 21, 2015 at 4:28 PM, Mark Post wrote: > >>> On 12/21/2015 at 08:09 AM, "Jousma, David" > wrote: > > All, > > > > We have for the longest time used a 256MB TFS for /tmp. Beauty of that > is > > with every IPL, the transient data is wiped out,

Re: managing /tmp

>>> On 12/21/2015 at 08:09 AM, "Jousma, David" wrote: > All, > > We have for the longest time used a 256MB TFS for /tmp. Beauty of that is > with every IPL, the transient data is wiped out, and start fresh again. > We've very rarely ever run into filesystem space

Re: RFE for COBOL run-time

On 2015-12-21, at 09:56, Frank Swarbrick wrote: > > Enterprise COBOL does not support VSE (z/VSE). VSE also has no Unix > subsystem, so I don't imagine BPXWDYN is supported either. VSE COBOL > does not (directly) support dynamic allocation of datasets at all, to my > knowledge. > BPXWDYN

Animation Industry using Mainframe

Hello, Are there any animation industry using Mainframe as the platform to build animations ? Question is Just out of curiosity. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: Animation Industry using Mainframe

Probably not enough horsepower. George Lucas' company Industrial Light and Magic was based in Tiburon when I was on the West Coast(mid eighties). Very secretive and lots of Crays. I don't remember which of the Star Wars had the long delay. He was quoted as saying they had to wait eight years

Re: Mainframe Capacity Planning

To me this is a very broad subject and lots of branches. What specifically do you need? Will this link help? Yes it is a vendor for hire website, but might provide some interesting thoughts http://nasi.com/IBM_Capacity-Planning.php Capacity Planning Planning for capacity means determining

Re: DOS descendant still lives was Re: slight reprieve on the z.

On 20 Dec 2015 18:15:48 -0800, in bit.listserv.ibm-main you wrote: >In <3555618195553184.wa.paulgboulderaim@listserv.ua.edu>, on >12/20/2015 > at 07:14 PM, Paul Gilmartin ><000433f07816-dmarc-requ...@listserv.ua.edu> said: > >>On Sun, 20 Dec 2015 20:11:27 -0500, Shmuel Metz (Seymour J.)

Re: Mainframe Capacity Planning

Search IBM LSPR z13 and you'll have an evening's light reading. https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprwork?Ope nDocument In a message dated 12/21/2015 10:47:11 P.M. Central Standard Time, stars...@mindspring.com writes: To me this is a very broad subject and

Mainframe Capaicty Planning

Hello All, I am not able to find good link for Mainframe hardware capacity planning and sizing. IF anybody have any reference, please share. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access

Re: DOS descendant still lives was Re: slight reprieve on the z.

jcew...@acm.org (Joel C. Ewing) writes: > No (about the "free", not about the "dead for decades"), DOS/VS was the > last really free base (last version Release 34?). Perhaps technically > DOS/VSE was "free", as there didn't appear to be a monthly licensing > charge for DOS/VSE itself

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

Of course 'it depends'. At least on the distance between the CFs. Signals are delayed by 10 usec/km. The number of signals traveling for SMCFSD have indeed been optimized since the beginning, but it still makes a difference if the CF's are 1 or 15 kms apart. Our latest researches from this

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

We're not going to BLANKET recommend System-Managed Duplexing for high-volume, high stringency structures such as LOCK1. SCA has little traffic. But I've seen MANY customers (including the one I worked with yesterday here in Istanbul) that successfully use it. And I support their use of it.

Re: Delete part of spool for active job

When I am in a situation, where spool is short, and any of these commands below are executed, then no, I don't care about the job number, because that is not how the candidate jobs are getting selected and cancelled/purged. CMD=(PASS1,,'MVS $CJ(E*,T*),SPOOL=(%>10),PURGE')

Re: DOS descendant still lives was Re: slight reprieve on the z.

> Endicott did something similar for e-architecture (4331 & 4341) > tailoredfor vs1 The 4300 did not come out of Endicott. It was developed in Germany, in the same lab that developes DOS/VSE. Tony Thigpen Anne & Lynn Wheeler wrote on 12/21/2015 03:05 AM: jcew...@acm.org (Joel C. Ewing)

Re: Coupling Facility Structure Re-sizing

Just to clarify a few points from this thread: The CFRM policy should specify INITSIZE for a structure only when that structure supports alter. It's not meaningful otherwise. The reason for the recommendation that SIZE should never be more than 1.5 - 2 times INITSIZE is that when the CF

managing /tmp

All, We have for the longest time used a 256MB TFS for /tmp. Beauty of that is with every IPL, the transient data is wiped out, and start fresh again. We've very rarely ever run into filesystem space problems. However, our DB2 sysprogs are running into problems when performing maintenance

RFE for COBOL run-time

I "stumbled" across this RFE is my wanderings. I think it is a good idea. You might want to vote for it if you do also: https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=78469 Enterprise Cobol support dynamic allocation for file (use of an environment variable named with ddname

Re: RFE for COBOL run-time

> Date: Mon, 21 Dec 2015 09:22:06 -0600 > From: john.archie.mck...@gmail.com > Subject: Re: RFE for COBOL run-time > To: IBM-MAIN@LISTSERV.UA.EDU > > ​I think it is not "full COBOL" in the sense that saying "per se" is not > "full English". "per se" is a borrowed phrase from another language

Re: managing /tmp

On Mon, 21 Dec 2015 13:09:18 +, Jousma, David wrote: > >We have for the longest time used a 256MB TFS for /tmp. Beauty of that is >with every IPL, the transient data is wiped out, and start fresh again. >We've very rarely ever run into filesystem space problems. However, our DB2

Re: RFE for COBOL run-time

On Mon, Dec 21, 2015 at 8:54 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 21 Dec 2015 07:01:22 -0600, John McKown wrote: > > >I "stumbled" across this RFE is my wanderings. I think it is a good idea. > >You might want to vote for it if you do also: > > > >

Re: DOS descendant still lives was Re: slight reprieve on the z.

No wonder they didn't break. On Mon, Dec 21, 2015 at 6:27 AM, Tony Thigpen wrote: >> Endicott did something similar for e-architecture (4331 & 4341) >> tailoredfor vs1 > > The 4300 did not come out of Endicott. It was developed in Germany, in the > same lab that developes

Re: Animation Industry using Mainframe

On 21 December 2015 at 08:54, Peter wrote: > Are there any animation industry using Mainframe as the platform to build > animations ? Not exactly animation, but a few years ago IBM was using in various ads a company in (iirc) Brazil who was using a z system for an online

Re: DOS descendant still lives was Re: slight reprieve on the z.

Not only the 4300, but also the MP3000, which also did not break. :-) Tony Thigpen Mike Schwab wrote on 12/21/2015 10:36 AM: No wonder they didn't break. On Mon, Dec 21, 2015 at 6:27 AM, Tony Thigpen wrote: Endicott did something similar for e-architecture (4331 & 4341)

Re: Animation Industry using Mainframe

Given that this is doing a lot of image processing, I'd lay good odds that they are not being done on GPUs using CUDA type code on an Intel box. On Mon, Dec 21, 2015 at 8:51 AM, Ed Finnell < 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > Probably not enough horsepower. George Lucas'

Re: Animation Industry using Mainframe

Peter wrote: >Are there any animation industry using Mainframe as the platform to build >animations ? Perhaps and it depends on what is animated at all and for what use is that animation. But you must define 'animation'. Do you mean changing a picture in a presentation? Say a growing arrow

Re: managing /tmp

Paul, Thanks for responding > Does this process not respect the setting of $TMPDIR? It should. I am looking into that, I'm hoping it does. > Be careful. You may simply unlink such files making them inaccessible to > other processes, but the space is not reclaimed until they're closed. Yes,

Re: RFE for COBOL run-time

On Mon, 21 Dec 2015 07:01:22 -0600, John McKown wrote: >I "stumbled" across this RFE is my wanderings. I think it is a good idea. >You might want to vote for it if you do also: > >https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=78469 > > >Enterprise Cobol support dynamic