开云体育

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

If you'd like to save some of us from losing more hair ;-) would you share your hercules configuration lines for VM and for MVS? I wasn't sure if I needed TCPNJE for both, either, or neither. ...

Martin was correct. I have a fix under test right now that correctly parses the case this thread stated with, and every other PARSE instruction in all the Rexx code I have. It was particularly

I want to be able to submit jobs to JES2 (MVS 3.8j TK5) from VM/370 1.2 CE, but don't want to run MVS as a guest under VM/370.? I get much better performance running a separate Hercules SDL instance

Hi Tony, You must have missed my many posts over on the Turnkey Group! For my IFOX00 refurbishment project I took the source code that was generated by Paul Gorlinsky’s excellent work and merged in

I think I have enough new building blocks in EE that RDRLIST should be doable in a similar way as XEDIT does. As a proof of concept, I have downstripped RECEIVE EXEC Y2 to use it as a PEEK macro. PEEK