开云体育

Probably showing my own ignorance here, but couldn't the minidisks be defined at the 1st level and mapped in the 2nd level's DIRECT using DEDICATE? I'd imagine that would be problematic with a large

Great to hear about this tip again, William. In 1986 I used it in some form of exercise, and the following years as a travelling systems programmer I never went without it in my clients'

One other small old timer tip regarding the CP nucleus.. You will definitely want to create a new Class-G user (I call mine CPCP) for running a 2nd-level CP.. Never load an untested nucleus to your

You should not need to rerun VRSIZE every time you rebuild the nucleus.

I also receive the same message upon ee exit. Is there a fix for this? Sorry if I missed the solution to this. Mike ** freeMem: ignored attempt to free NULL Memory overwrite detected by __DMSFRT at

Here's an update.? After extensive testing and numerous suggestions from others in the community, I think I have found an answer. On the VM/RSCS side, you need to start the line with a buffer size

Aha ... that makes sense! So... Would that mean that, whenever I run VMFLOAD VRLOAD DMKLCL , there should no longer need to re-run VRSIZE, as long as I moved the resulting DMKSLC TEXT A filo onto the

So... here's the deal VMFLOAD is an EXEC that creates a "nucleus load deck". It takes its input from another EXEC that is a list of files to be concatenated into a single "punch" file. . The thing

Hi, thank you for your help. The fun thing is that, while I got it to work by switching from what I learn from documents to do: VMFLOAD VRLOAD DMKHRC to VMFLOAD VRLOAD DMKLCL by applying the 'LCL

when rebuilding the nucleus replace this: ?? vmfload *_cp_*load dmklcl with this to maintain v=r: ?? vmfload _*vr*_load dmklcl

Hi folks. After yet another adventure messing with DMK*** stuff (now I've been playing with DMKBOX out of curiosity from the last threads), I have realized that, always, whenever I rebuild the

I still can't punch jobs to MVS from VM for some reason but, in tests today, output routed from MVS to VM transfers with no I/O errors.? So far, I have routed jobs with various amounts of output,

Hi Jeff: I've gone both up and down in buffer size. I can send a short command or a short JCL from RSCS to JES. ?No problem there. ?But when I send a larger job, maybe 20 lines, the IO

Hi Daniel, Try using the following for your RSCS link start command: START NODEA PARM H02 B999 Page 35 in the manual "GC20-1816-3 VM/370 Remote Spooling Communications Subsystem Users Guide,

I am working on a prototype of RDRLIST+PEEK running inside EE. Which features are most important for you to have as a Proof Of Concept ? EE does not have special functionality for RDRLIST+PEEK, just

Thanks for that pointer Mark...it is at least enlightening. ?Perhaps someone else can better interpret the message, but to me it looks like a read error on the JES2 side. [1] View/Reply Online

Look at the manual, and search for $HASP094, around page 98 of 416. There is an explanation of all the bits

The /*ROUTE RPINT RMT1 is intentional, to not crash the connection back to the VM/RSCS side. Otherwise, we see the IO errors (which is what I'm trying to resolve).

IIRC when you submit from a remote station (VM, or RJE) and you want the output back to that station, you need the /*ROUTE as you specified, otherwise it will attempt to print on the "local" MVS

The scenario posted is without tcpnje. On the MVS side we have: # RJE 0670 2703 dial=IN lport=3780 0671 2703 lport=3781 rhost=localhost rport=3880 dial=no Device 671 is the RSCS connection. On the