开云体育

The spirit has left the bottle and will never return: EE has run its first REXX macro. This version is still incomplete and not stable enough for public display. Now there is MUCH legwork to be done

Bertram Moshier wrote: I'm surprised no one mentioned Tom Brennan's Vista 3270: * https://www.tombrennansoftware.com/ It supports custom screen sizes up to 99 lines by 200 characters wide. It's not

See A sobering finding (Re: Automatic generation of transcoding tables for IND$FILE) ( /g/h390-vm/message/4325 ) ZOC only implements the terminal side, it uses the IND$FILE already

Hi Betram, according to this, WC3270 does support a 3278 Model 5, so your 132 columns display should be fine: http://x3270.bgp.nu/Windows/wc3270-man.html *-model*/name/ The model of 3270 display to be

That mention revived some pleasant memories. ZOC became my 'go-to' dial-up terminal program, replacing ProCOMM Plus (under Win/OS2) back in my OS/2 days. DeWayne

Hi Martin, Does ZOC distribute its own IND$FILE MODULE? The one from MECAFF is only documented to work on the Vista emulator and on WC3270. I can't distribute any IBM IND$FILE MODULE on VMCE, but the

ZOC (commercial software for MS Windows and macOS) has a very generous evluation policy. It has 3279 132x27 wide screen and 3270 IND$FILE Transfer inside. Sample screenshot (

Hi, I'm wonder if WC3270 supports 132xNN and 3279. Also how do I get it to use 132 columns, color, etc? I really need the wider screen to read various files, etc. Thank you.

I've been following this thread about possible bug in the Parse instruction, and thought I might weigh in.? While the desired behavior would be to break the parse target on literals first, my reading

OK. I get it. It isn't different C libraries. In modern terms there are two separate ABI (application binary interface) stacks that do not communicate between each other. Or, perhaps a better

Martin is exactly right. What I call "the C runtime environment" is the CMSCRAB control block which is basically the R13 save area for the currently running C function, and other pointers for stack

It is the dynamic data, not the code. * a user "kicks" CMS to start EE, EE initializes its runtime data * EE calls CMS for macro execution * CMS sees "/*" and starts bREXX, bREXX initializes its very

As I am not in the weeds like some of you, can you help me understand how we ended up with two distinct C runtime environments? And how did you run into the same thing with BREXX?Just curious. Did we

Hi Martin, You are correct in that CMS calling sequences, program management structure, and interface to supervisor services know nothing about the GCC compiler runtime interface. Enabling EE to use

It is R13. AFAIK CMS does not know anything about GCCCRAB, therefore the SUBCOM entry handler does not know what R13 should point to. *@DSTAKIN* expects specific things through R13, see file *DYNSTK

If you have VM/370 CE 1.1.2 up and running, look at the ASSIST EXEC on the Y minidisk, for a working example of how to get around the PARSE problem. If you don't have it, look at ASSIST_VM370_etc (

Bertram, VM or rather Hercules will use more than one core, which is one reason it performs well. Remember that the 30xx boxes had, for their time high performance and sophisticated IO systems.

Hi, Thank you for the information. I understand and agree why you didn't get the AP working. I have a Dell Precision 7910 with dual E5-2667 v3 and 128GB of RAM. I just like the idea of a VM version

The use case for an AP VM/370 servicing single CMS user is? CMS doesn't multitask; it doesn't even generally do asynchronous disk I/O. An UP VM/370 under Hercules running on a modern host kicks the

Thank you for your information.