RE: Re: Announcing the VM/370 and VM/380 "SixPack" version 1.2 release candidate 1!

Right now have it all on my PC. Looks like the "FILEDEF * CLEAR (" command
now works so PL/1 should be just fine.

 

Dave

 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Kevin Leonard
Sent: 15 October 2010 03:06
To: [email protected]
Subject: [H390-VM] Re: Announcing the VM/370 and VM/380 "SixPack" version
1.2 release candidate 1!

 

  

Bob:

This is awesome. Thanks for all the work you've put into it.

I've tested CMS/DOS and CMS/VSAM (testing VSAM both under OS
simulation and DOS simulation). Everything works as expected.
You might want to add a "LINK DOSSTART 148 148 RR" to the CMSUSER
virtual machine definition so the DOS/VS sysres will already be
available for CMS/DOS use. I'd suggest adding an ACCESS 148 command
to the CMSUSER profile, but I don't know what letter people might like
to use for the DOS sysres. Typically I use Z, but that's an artifact
of my first VM job more than 30 years ago, and Z is often used for
other things.

Another thought: because I wasn't able to fit CMSVSAM above the
15MB line, an attempt to use VSAM in the default CMSUSER machine
configuration fails with:

DMSBOP401S V.M. SIZE (0F00000) CANNOT EXCEED 'CMSVSAM' START ADDRESS
(E00000)

We probably should either document the message and user response
(define virtual machine size as 14M and re-IPL), or change the
default machine size for CMSUSER to 14M.

Hell, we should probably document a lot of things about CMS/DOS,
but right now it's nice just to have it available. I'll put writing
that documentation on my list of things to do, somewhere after dealing
with all the code page related issues.

The REXX interpreter is outstanding, something I never expected
to see in VM/370 R6.

I tried my JES3 global configuration with an ASP main. The ASP
system connected, and it ran a FORTRAN compile, link and go under
ASP as expected. There's an occasional problem with a CONTINUOUS
PAGING ERRORS threshold exceeded error that results in a wait00F,
but that dates back years, at least to the original four-pack system,
and I've never been inspired enough to figure out what's causing it.
JES3 is the only thing that ever produces it. My lazy circumvention
is to have DMKPAG not count paging errors, but some day I need to
find out what is actually going on.

I'm wondering if the PL/I front-end processor error got fixed.
PLI EXEC Y2 is still there, and PLI MODULE Y2 still has a
date of 12/29/03. The problem was that the front-end had
an extraneous "(" in the FILEDEF CLEAR which was causing some
file allocations to be left because FILEDEF CLEAR doesn't
permit options. My local fix to the PLI ASSEMBLE source was:

./ * --------------------------------------------------------- HRCXXXDS
./ * HRCXXXDS 2010/01/18 - Fix syntax error in FILEDEF CLEAR HRCXXXDS
./ * caused by "(" after "CLEAR" (no HRCXXXDS
./ * options are permitted for FILEDEF HRCXXXDS
./ * CLEAR). HRCXXXDS
./ * --------------------------------------------------------- HRCXXXDS
./ R 00792000 00792000 $ 792000 10 01/19/10 01:15:00
** DC CL8'(' LINE DELETED BY HRCXXXDS

and delete the PLI EXEC.

Thanks again for an outstanding effort.

-- 
Kevin