开云体育

I was going to build a 6.7 system just for fun, and so I can take a gander
at VTP. I have the 6.7 package and the tapes, and have built the DASD.
Kipling the starter system works, but to get past the hardcopy prompt, I
have to have both a 3270 at 010 and a 3215 at 01F connected, then reply R
00,'HARDCPY=(01F,ALL,CMDS)' to the prompt. (IPLing with both consoles
connected will cause the initial interaction to be on the 3215.) Once
things are started, a V 010,MSTCONS will switch to the 3270.

But...once I've got things up, I can't seem to get anywhere. I can devinit
a JCL file to the reader, and SF ,00C works...and reads in the job, and
doesn't do anything. The job is in class V, and I'm guessing the P00
partition is set to class A. D <jobname> shows the job sitting there
waiting. How do I get things to actually run?
--
Jay Maynard

Jay,
E jobname,CLASS=A
may work?
Gary

Hi,

I put up my OSVS1 6,7 up on my web site with my other automatic
builds. I too would like to try VTP, but there is not much
documentation about setting it up.



Rich

Hi Jay,

If you wish, you can IPL with just the 010 console present. it will be the master console and no Vary command is needed. If you are prompted for a hardcpy, you can answer R 00,'HARDCPY=(SYSLOG,ALL,CMDS)' and then you do not need to have an 01F device unless you just want to.

As for the partition job classes, you can reassign them permanently in the DFN01 member of SYS1.PARMLIB. Or, you could use the RESET command as a previous poster suggested, to change the class of that particular job. Or, a better choice for the life of the IPL would be to issue a modify command to tell the initiator to use whatever classes you want. For example:

F P1,CLASS=AV

I always run VS1 in a virtual machine, and I have TK4 MVS in a virtual machine as well right along side of it. That way, I can use TSO on MVS to edit the parmlib members or proclibs members of the VS1 volumes without having to do everything in batch. MVS and VS1 can share the VS1 dasd in R/W mode, if you define them correctly in the CP directory, using MDISK statements with MWV. The V in MWV is the critical specification - it forces CP to ensure data integrity between the guest OS'es using virtual reserve/release.

Another plug for running VS1 under VM, if you spool the printers in VS1 to your CMS userid, then all your VS1 output will go there (if it has a WTR started to the output class of the job), and you can then view that output in CMS. You can of course submit jobs to VS1 via the virtual punch in CMS right to VS1's reader. So CMS can provide a convenient online platform to use VS1 for job JCL and viewing output. Just like it used to be in the early 1980s!

Regards,
Bob

On Sat, Dec 25, 2021 at 11:56 AM, Jay Maynard wrote:

D <jobname> shows the job sitting there waiting. How do I get things to actually run?

Maybe you can try to change the execution class of the job?

e <jobname>,class=a

Cheers,

Rene FERLAND, Montreal

On Sat, 25 Dec 2021 at 18:57, Bob Polmanter <wably@...> wrote:

[...]
I always run VS1 in a virtual machine, and I have TK4 MVS in a virtual
machine as well right along side of it. That way, I can use TSO on MVS to
edit the parmlib members or proclibs members of the VS1 volumes without
having to do everything in batch. MVS and VS1 can share the VS1 dasd in
R/W mode, if you define them correctly in the CP directory, using MDISK
statements with MWV. The V in MWV is the critical specification - it
forces CP to ensure data integrity between the guest OS'es using virtual
reserve/release.

Have to be careful with this... Support for reserve/release on the
virtualized hardware doesn't mean that MVS or VS1 will issue them. The
devices have to be gen'd shared in the guests as well. And even then, the
integrity is only for VTOC updates - there is no general protection against
updating a dataset from both systems at the same time. For that you need
some scheme to propagate ENQs across systems - something IBM didn't provide
until much later with GRS via CTCs. There were some third party products
that did, but presumably we don't have access to those.

Tony H.

Hi Tony,

MVS TK4 was generated with FEATURE=SHARED on all DASD, and when I did the sysgen for VS1 6.7 I also used FEATURE=SHARED.

I'm only concerned about VTOC updates. I have no intention nor any applications that try to do multi-write access to a common dataset to both systems for example. Again, this is just to simply by allowing TSO to edit a VS1 PARMLIB member (for example) to avoid the need to otherwise update that member with a batch job executed within VS1. It's perfectly safe to create or delete datasets on VS1 volumes using MVS TSO (although the VS1 catalog won't know about the operation), with FEATURE=SHARED on both systems and MWV on the MDISK statements in the CP directory.

Regards,
Bob