headers
Simon Williams | 9 Nov 2010 14:51
Favicon

Re: State of Turnkey

 

> halfmeg wrote:
 
>> Simon Williams wrote:

>> I have finally got round to giving the Turnkey 3 Update Beta a go
>> and have achieved some success, particularly in that I now have a
>> viable JES3 installation. I fed back my experiences to Carlos and
>> he has asked me to share them with the group.

>> I was a standard Turnkey 3 system, built from the starter system
>> using the sysgen instructions on the CD.

>So as to be clear about your setup, you have 2 separate environments. One that you built from starter system up and the other TK3UPD BETA?
 
No, my setup was still very much an experimental one and I so I replaced the DASD images I had created with those in the update.  I had created the system by following both the MVS Sysgen and MVS Customization sections of the New User Cookbook.  I ran all scripts (having to fix makeadisk as it appeared to assume an earlier version of dasdload, which used different parameters) and all the sg* and mvs* jobs.  The only ones I didn't run were those that removed accepted PTFs and, predicatably for am IT professional, the ones that took snapshots of the system!

>> The machine I am running on is a Toshiba i686 laptop with Nvidia
>> graphics running Debian Squeeze (all packages up to date as of
>> Saturday). My Hercules is 3.07 as packaged for Debian. I had added
>> extra printers, readers, terminals, tapes drives and lots of DASD to
>> the Turnkey 3 system and had the number of CPUs set to 2, but the
>> sysgen was standard (as I have not yet managed to find instructions
>> for rerunning the sysgen for an existing system).

>Am not sure if the jobstreams for IOGEN or MINIGEN were ever posted.

>> Everything worked reasonably well, although I had not got startrek
>> to work under TSO, it just told me it didn't exist!

>Possible that JES3 parml ib entries don't have all that is needed yet. JES3 is very new addition to TK3 so there may be many issues to be resolved.
 
It was under JES2 on the initial turnkey system that startrek couldn't be found!

>> Once I had loaded the updates (just unzip the downloaded archive
>> into the directory containing conf, dasd, etc.),

> Hmmm, not correct. TK3UPD is a self contained environment. Unzipping it into already populated directories may give unpredictable results.
I can't see why it should, given that entire DASD images would be overwritten, except in the case of changes in shadow files where the base image was overwritten and the shadow file contain updates to the original.  I don't think I had shadow files on the images replaced by the update, but I can't be sure.  I will try using the update as a standalone system and then add the other stuff back in and see what happens!

>It does not have the CBT or MVS source DASD, but every thing else should be there. See post:

> http://tech.groups.yahoo.com/group/turnkey-mvs/message/6781

>Don't have the README.TXT handy right now, but don't believe I mentioned overlaying anything already existing.
You didn't.  I saw that the zip file did not contain all the DASD images that the CD created and assumed that that meant the update only replaced certain images.  My mistake.

>To regain use of CBT and MVS source DASD you can copy them into the DASD directory. At least I believe I left the entries in the tk3upd.conf >file.

>> I IPL'd the emulator and (after some very scary messages during the
>> initial JES2 startup and subsequent failure!) managed to do a cold
>> start of JES2 and all looked reasonably good.

>Sounds like normal initial JES2 start, thought that was mentioned in the Turnkey Cookbook but don't see it currently.
The messages weren't the ones in the Cookbook, very different, but a cold start sorted them out with no problem.  It could have been to do with confusion resulting from me updating an existing system rather than IPL'ing the update standalone.

>> One point I did note was that CMD1 abends S106 on every startup.

>Under JES2 or JES3 ? Either way possible side effect of mixing system built previously with TK3UPD. If JES3 only, then possible parmlib or >memory size issue.
 
Same result under both JES3 and JES2, but I'll let you know once I've attempted a standalone IPL of the update.

>> I then tried amending the config to include NUMCPU=2 and
>> consistently had a problem with a processor spin being detected on
>> the second CPU. This happened occasionally with the original
>> Turnkey 3 installation, but now happens consistently. I have fallen
>> back to a single CPU and that seems to be fine.

>This has been a intermittent issue for a while which I would like to resolve. Did your initial build of TK3 from scratch add all the PTFs or did you >build as Jay Moseley's build with minimum PTFs ?
 
As above, I did the full build.
>Which Hercules versions have you used and did one in particular permit using 2 CPUs without many problems?

Exactly the same build 3.07 rarely gave me a problem under standard Turnkey 3, but got it consistently under the update.  I will report back after I try the update stand alone.

>> When I originally tried to start JES3 (IPL and then r 00, sysp=j3),
>> I had a problem as it was complaining that it didn't have a console
>> on device 0009 (it has been moved to 001F).

>And it may have been moved back to 009. I can't remember right now what the issue was but a post mentioned 01F which is no longer correct if it >was moved back to 009. Believe the address is in the JES3INISH deck.

>> It was also complaining about a missing printer at 030F and a
>> missing console on 00C6.

>30F is known issue, 0C6 is something which I don't recall at all.
0C6 is defined as the JES3 console!!!!

>> I added these by duplicating the telnet definition on 001F for
>> 0009, duplicating the printer on 030E (with a different file name)
>> for 030F and adding a 3270 device on 00C6. All terminals are
>> connected before IPL, that is telnet x 2 for devices 0009 and 001F
>> and X3270 x 6 for devices 0010, 0011, 00C0, 00C1, 00C2 and 00C6.
>> Once I had done this, JES3 started with no problems.

>> Once I had this up and running, I tried logging in to TSO, which
>> worked, but I got a couple of abend messages during statup and my
>> brief testing (the other half was nagging me to stop playing with my
>> toys as we had important stuff to do!) showed that although TSO was
>> functional, t here are problems with it.

>> Startrek couldn't find a couple of files (although it didn't run at
>> all in the original, so it was a step in the right direction), but
>> more worryingly RPF would not run.

>STARTREK has issues due to the load modules which were part of the CBT file 35, quick add of modules, are depending upon Fortran runtime >libraries TK3 doesn't have. We only have G & H. The source for STARTREK on CBT is for a later version of Fortran. The fix is minor in that a >format statement needs to be added for input variables. The fix is major in that it needs over 100 of these to be 'fixed'.>

>RPF and other things may be due to PARMLIB entries missing for JES3.
I tried loading RPF 153 onto the system from the distribution tape last night and it didn't cure the problem, although I'm not sure that it would if the problems I am having are down to replacing existing DASD images with those I on the update and mixing those in with images from the existing system.  As I said earlier, my system is very much an experimental one at present (although I am intending it to become more of a hobby).  It currently has no value so I think I will starrt again using TK3UPD as the base.  I still have all the control files I set up to create my extra DASD and the rest is just configuration editting.  I'll report back in a couple of days.

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 9 Nov 2010 20:57
Picon
Favicon

Re: State of Turnkey

 

> Simon Williams wrote:

> > halfmeg wrote:

> >> Simon Williams wrote:

><snip>

DASDLOAD parms did change since TK3 CD created in 2002.

> The only ones I didn't run were those that removed accepted PTFs
> and, predicatably for am IT professional, the ones that took
> snapshots of the system!

Sounds about right for TK3 from scratch.

> >> Everything worked reasonably well, although I had not got
> >> startrek to work under TSO, it just told me it didn't exist!

><snip>

> It was under JES2 on the initial turnkey system that startrek
> couldn't be found!

StarTrek ( SUPRTREK ) was not in original TK3. It was added later.

> >> Once I had loaded the updates (just unzip the downloaded archive
> >> into the directory containing conf, dasd, etc.),

> > Hmmm, not correct. TK3UPD is a self contained environment.
> > Unzipping it into already populated directories may give
> > unpredictable results.

> I can't see why it should, given that entire DASD images would be
> overwritten, except in the case of changes in shadow files where the
> base image was overwritten and the shadow file contain updates to
> the original. I don't think I had shadow files on the images
> replaced by the update, but I can't be sure. I will try using the
> update as a standalone system and then add the other stuff back in
> and see what happens!

Most likely it shouldn't, however if one uses a Hercules configuration file which is not the one which goes with the overlay, bad things may happen. One instance was an individual was getting JES2 failure due to missing JES2 PARMS. They are on one of the JES2 shadow files and either he used an incorrect configuration file or dropped the shadow images somewhere along the line.

> >> I IPL'd the emulator and (after some very scary messages during
> >> the initial JES2 startup and subsequent failure!) managed to do a
> >> cold start of JES2 and all looked reasonably good.

> >Sounds like normal initial JES2 start, thought that was mentioned
> > in the Turnkey Cookbook but don't see it currently.

> The messages weren't the ones in the Cookbook, very different, but a
> cold start sorted them out with no problem. It could have been to
> do with confusion resulting from me updating an existing system
> rather than IPL'ing the update standalone.

Remember now that initial JES2 failure is expected and then a COLD start has to be performed due to the way I erased the SPOOL to distribute minimum size. This is not documented in the Cookbook but on a forum post for TK3SU1 IIRC.

> >> One point I did note was that CMD1 abends S106 on every startup.

> >Under JES2 or JES3 ? Either way possible side effect of mixing
> > system built previously with TK3UPD. If JES3 only, then possible
> > parmlib or memory size issue.

> Same result under both JES3 and JES2, but I'll let you know once
> I've attempted a standalone IPL of the update.

Just laid out a fresh TK3UPD and CMD1 was fine. Maybe due to your situation of DASD images. Don't know.

><snip>

> >Which Hercules versions have you used and did one in particular
> > permit using 2 CPUs without many problems?

> Exactly the same build 3.07 rarely gave me a problem under standard
> Turnkey 3, but got it consistently under the update.� I will report
> back after I try the update stand alone.

Thanks,

><snip>

> >> It was also complaining about a missing printer at 030F and a
> >> missing console on 00C6.

> >30F is known issue, 0C6 is something which I don't recall at all.

> 0C6 is defined as the JES3 console!!!!

Still don't remember 0C6 as anything which stands out, but my brain has been on sabbatical for a while. Did define a JES3 console somewhere and checked to make sure it worked. No idea why 0C6 got selected for the honor at present.

><snip>

> >> All terminals are connected before IPL, that is telnet x 2 for
> >> devices 0009 and 001F and X3270 x 6 for devices 0010, 0011, 00C0,
> >> 00C1, 00C2 and 00C6.
> >> Once I had done this, JES3 started with no problems.

Please tell me you didn't have to have them all operational to IPL.
Should only be 1, 010. 0C0 needed for TSO and eventually 0C6 so JES3 console doesn't halt system when buffer full. It's been a while so may have it a little off.

><snip>

> although I'm not sure that it would if the problems I am having are
> down to replacing existing DASD images with those I on the update
> and mixing those in with images from the existing system. As I said
> earlier, my system is very much an experimental one at present

><snip>

> I think I will starrt again using TK3UPD as the base. I still have
> all the control files I set up to create my extra DASD and the rest
> is just configuration editting.

> I'll report back in a couple of days.

Another thing which occurs to me is the movement of some DASD to new device addresses. This took place to fit into the VM scheme yet the suffix numbers on the DASD files remained as they were originally named. It might look a little strange and confusing but is ok. What isn't ok is attaching a device on the wrong device address for which it isn't genned. IE, attaching a 3350 on a 3380 UCB, 3330 on 3350 UCB or similar. Not that you have done this, but I have and got very strange results and much scratching of head until I realized what had happened.

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Simon Williams | 11 Nov 2010 15:08
Favicon

Re: Re: State of Turnkey

 

Okay, busy night last night and this morning, but I have reinstalled the Turnkey 3 Update and am happy to report that everything is looking a lot healthier than after my first attempt!

 

Firstly, I deleted everything I already had, it was broken anyway!  I then installed a new system (original) from the TK3 CD image, which all worked as expected.  I then installed created a TK3 Update system from the ZIP file.  Again, all looked good, although JES3 wouldn't work (more on that later), so I decided to take the plunge and start setting the system up how I wanted it.

 

I then got distracted by installing hebe, which in return required me to compile my own hercules to allow an external GUI. Hebe is great and I will be posting a separate article on that experience later.  With my nice shiny new GUI interface in place, I started the task of creating a TK3UPD based system that was configured how I wanted it.

 

I unzipped a new system (bsp1) from tk3upd.zip (I wanted to leave the one from earlier pristence for reference), copied from the standard system the missing DASD images (CBTs, MVS source, etc) and set about editting the configuration.  I added a 3215 at 0009 and uncommented the one at 001F.  I added a 3270 at 00C6 (the JES3 console as I knew from my previous experience) and a 1403 at 030F (again I knew from previous experience JES3 would look for it).  I uncommented the 2703 and 3705 definitions and set CPUNUM=2.

 

I held my breath, IPL'd the new system, gave it an r,00,clpa and JES2 bombed, as I knew it would.  I then cold started JES2 and everything leapt into life!  I logged in to TSO and RPF worked fine (still got two ABENDs on my first log in, but it all worked afterwards and got no ABENDs on subsequent logins.  After playing for a while to ensure all was okay, I shut down and reIPLd and gave it an r 00,sysp=j3 to fire up JES3.

 

The JES3 cold start gave me an S213-04.

 

A bit of investigation led me to the fact that SYS1.JES3DRDS, although catalogued, did not exist. I then remembered the FIXJES3 JCL that I had been given, checked that and sure enough, it creates SYS1.JES3DRDS, so I ran that and tried again.

 

This time, JES3 came up, in that the console sprang to life, but I couldn't start JSS. ReIPL'd back into JES2 and did some investigation.  Nothing seemed to be awry, so I tried again.  This time it ABENDed U0004 telling me there were catastrophic errors during initialisation.  It was after midnight, so I went to bed to sulk!

 

This morning I thought I'd have one more go while I ate breakfast.

 

Processor spin!  I'd almost forgotten about that.  I'd been bringing the system up and down without that problem  ever since the re-install!

 

Then it struck me.  That message buried in the logs that I had ignored about not recognising CPU 001006688 (or something, I can't remember the exact number off the top of my head).  Into the configuration, NUMCPU=1, saved it restarted hercules, r 00,sysp=j3, JES3 cold start, *s jss, start VTAM, start TSO and everything is working!!!  I put the network and TSO startup into COMMNDJ3 and it still came up as expected.

 

I was late for work!

 

Tonight, make JES3 the default system, have a play with the 3705 stuff and find a decent JES3 Cheat Sheet as I was never an expert and my memory isn't what it was!

 

Life is good in geek heaven!

 

Regards

 

Simon


__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Kevin Leonard | 11 Nov 2010 23:00
Picon
Favicon

Re: State of Turnkey

 

Simon:

> Okay, busy night last night and this morning, but I have
> reinstalled the Turnkey 3 Update and am happy to report that
> everything is looking a lot healthier than after my first attempt!

Congratulations, and thanks for the detailed report on what you've
done. It's hard to put this stuff away, isn't it? When things
aren't working, you get so frustrated that you don't want to stop
until you've figured out what's wrong. When things start to work
right, you don't want to stop because you're having so much fun.

Let us know about anything you encounter using JES3. Up to this
point, we really haven't had an experienced JES3 person exercising
the JES3 environment. I've been filling that role by default; I'm a
retired JES2 system programmer who got fascinated by JES3. Whatever
is broken, I probably had something to do with us. When you find
something that doesn't work, or have a suggestion on how we could
do it better, let us know. Hercules is a learning experience for
all of us.

The Turnkey 4 beta effort has had its ups and downs, as people have
real-life commitments that take priority over Hercules. In its more
active moments, the TK4 project has made some progress with respect
to JES3. The "Files" section of the TK4 beta forum:

http://tech.groups.yahoo.com/group/hercules-tk4-beta/

has quite a few JES3-related files. It's been so long, though,
that I'm not absolutely sure of the current state of anything.
My personal JES3 environment has probably seen quite a bit of
changes since the last time I used it to build a prototype Turnkey
environment. When we get back to TK4 JES3, I think I'm probably
going to have to start over and rebuild everything from scratch
to make sure I don't miss anything.

> I added a 3270 at 00C6 (the JES3 console as I knew from my
> previous experience) and a 1403 at 030F (again I knew from
> previous experience JES3 would look for it).

We did, I think, pretty much decide that the JES3 display console
is supposed to be at 014. The existing TK3 system didn't have a
UCB there, so we ended up borrowing one of the VTAM 3277 addresses.
The TK3 update system I'm looking at does have 014; if yours does,
you could move the JES3 console from 0C6 to 014.

Addresses for the MLOG printer and JES3 procedure "JES3OUT"
printer have gotten moved around by non-JES3 requirements. I
think I finally gave up trying to use the 30x range; in my personal
JES3 system, I've moved MLOG to 31E and JES3OUT to 31F, but those
assignments have never been implemented in the TK system and the
TK3 update system I'm looking at doesn't have UCBs generated for
those devices. Until that happens, 30F is probably going to have
to do.

If you set your JES3 display console to "*DELAY,0" and let the
screen fill up, you may experience an abend200 in JES3 because
the console services processor forgets to restore a register
before trying to write the "DISPLAY HALTED" message. The fix
is a usermod:

http://www.j76.org/vs2/tiat803.zip

I don't know if you've gotten far enough to think about the
possibilities of a multi-system JES3 complex. Unfortunately,
right now Hercules CTC support isn't robust enough to meet JES3
requirements. That's on the list of desirable features to add,
and has been for a while. I have built a functional complex using
guest machines under VM with JES3 global, JES3 local and ASP real
main, so when Hercules supports it we can do it.

> Life is good in geek heaven!

Awesome. Have a good time.

--
Kevin

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 12 Nov 2010 01:00
Picon
Favicon

Re: State of Turnkey

 

> Kevin Leonard wrote:>

> Let us know about anything you encounter using JES3. Up to this
> point, we really haven't had an experienced JES3 person exercising
> the JES3 environment.

Yes, by all means post when you run across something post about it. My JES3 experience was totally in Operations not Systems.

> I've been filling that role by default; I'm a retired JES2 system
> programmer who got fascinated by JES3. Whatever is broken, I
> probably had something to do with us. When you find something that
> doesn't work, or have a suggestion on how we could do it better, let
> us know. Hercules is a learning experience for all of us.

> The Turnkey 4 beta effort has had its ups and downs, as people have
> real-life commitments that take priority over Hercules. In its more
> active moments, the TK4 project has made some progress with respect
> to JES3. The "Files" section of the TK4 beta forum:

> http://tech.groups.yahoo.com/group/hercules-tk4-beta/

Hmmm, how do I put this. The BETA group forum is not open or accessible to non-members. Membership was on an invitation basis when it was formed.

> has quite a few JES3-related files. It's been so long, though,
> that I'm not absolutely sure of the current state of anything.

It has been a while and will take some time for those who participate in the group to refresh themselves on items if need be. It may be a little longer still. The past 5+ years have been difficult for many of us. I started looking at SORT as a smaller project to get my brain back into thinking about mainframe stuff.

><snip>

> We did, I think, pretty much decide that the JES3 display console
> is supposed to be at 014. The existing TK3 system didn't have a
> UCB there, so we ended up borrowing one of the VTAM 3277 addresses.
> The TK3 update system I'm looking at does have 014; if yours does,
> you could move the JES3 console from 0C6 to 014.

> Addresses for the MLOG printer and JES3 procedure "JES3OUT"
> printer have gotten moved around by non-JES3 requirements. I
> think I finally gave up trying to use the 30x range; in my personal
> JES3 system, I've moved MLOG to 31E and JES3OUT to 31F, but those
> assignments have never been implemented in the TK system and the
> TK3 update system I'm looking at doesn't have UCBs generated for
> those devices. Until that happens, 30F is probably going to have
> to do.

TK3 final edition or TK4 for adding the above ?

> If you set your JES3 display console to "*DELAY,0" and let the
> screen fill up, you may experience an abend200 in JES3 because
> the console services processor forgets to restore a register
> before trying to write the "DISPLAY HALTED" message. The fix
> is a usermod:

> http://www.j76.org/vs2/tiat803.zip

Believe I added this to TK3UPD.

><snip>

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Kevin Leonard | 12 Nov 2010 04:28
Picon
Favicon

Re: State of Turnkey

 

> Hmmm, how do I put this....

Sorry about that. I've been away so long I'm losing track of
basics. I apologize to anyone I've inadvertently misled. It
might be helpful to post some JES3 things in this group's "Files"
section. Except as you noted, an awful lot of what we've posted
tends to be in the range of three years old. Probably what I
*really* need to do is get back to work and post updated files
in places that everyone can get to them.

> > http://www.j76.org/vs2/tiat803.zip
>
> Believe I added this to TK3UPD.

Good. It looked to be missing from the version I've got, but
then, I have no idea how old the version I've got is. Like I
said, I'm losing track.

> > Addresses for the MLOG printer and JES3 procedure "JES3OUT"
> > printer have gotten moved around by non-JES3 requirements. I
> > think I finally gave up trying to use the 30x range; in my
> > personal JES3 system, I've moved MLOG to 31E and JES3OUT to
> > 31F, but those assignments have never been implemented in the
> > TK system and the TK3 update system I'm looking at doesn't
> > have UCBs generated for those devices. Until that happens,
> > 30F is probably going to have to do.
>
> TK3 final edition or TK4 for adding the above ?

If it's possible, I'd say both TK4 and TK3 final should probably
use the 31E/31F addresses (or something other than 30F, anyway).
30F is generated as an MCS output-only console, and appears to be
reserved for automount support. The TK3 stage 1 I'm looking at,
dated 2009/09/18, has a comment that "Console 30F is intended
for an Automount system and should only receive ROUTCDE=3 msgs".
Because 30F is an output-only MCS console, JES3 can share it, so
routing the MLOG there produces the undesirable result as shown by
DISPLAY CONSOLES:

CONSOLE/ALT COND AUTH ID AREA NBUF ROUTCD
30F/JES S NONE 08 3

If 30F is supposed to be dedicated to automount support, we don't
want JES3 messages going there.

That TK3 stage 1 also defines 014 and 016 (reserved for JES3 display
consoles) as MCS display consoles, which I think we already talked
about and decided we wouldn't do. The running TK3 update system
I've got doesn't have 014 and 016 defined as MCS consoles, so it's
quite possible you've already fixed that.

The JES3 initialization deck still has 0C6 as its display
console, but the MVS system has UCBs for 014 and 016, the two
displays we set aside for JES3 consoles. We need to fix
the JES3 initialization deck display console address to move
it to where we had intended it to be.

The initialization deck generally requires review; the one
I'm looking at in SYS1.PARMLIB(JES3IN00) has a comment date
of 2006/12/19. I'll work through that and let you know what
I come up with.

Both the stage 1 and the TK3 update system I'm running do not
include any dummy subsystem console UCMs defined with "TYPE=JES":

CONSOLE TYPE=JES,VALDCMD=(1,2,3)

which prevents MVS commands from being issued using the JES3
display console (an attempt to issue one gets the error message
"IAT7130 'cm' REJECTED, NO MAIN CONS SUPPORT"). There should be
at least two subsystem UCMs (one for each JES3 display console).
Three or four would be even better, in case someone gets really
excited about JES3 consoles.

Again, I'm not sure about the version of TK3UPD I have. Can I
download a current copy from somewhere so we're all shooting at
the same target?

--

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 12 Nov 2010 22:09
Picon
Favicon

Re: State of Turnkey

 

> Kevin Leonard wrote:

><snip>

> Again, I'm not sure about the version of TK3UPD I have. Can I
> download a current copy from somewhere so we're all shooting at
> the same target?

http://www.4shared.com/file/RfClJ57w/tk3upd.html

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Kevin Leonard | 13 Nov 2010 03:21
Picon
Favicon

Re: State of Turnkey

Permalink | Reply |
headers
saucyjacks-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org | 12 Nov 2010 11:04
Favicon

Re: State of Turnkey

 



--- In turnkey-mvs-hHKSG33TihhbjbujkaE4pw@public.gmane.org, "Kevin Leonard" <kl_j76 <at> ...> wrote:
<--snip-->
>
> Let us know about anything you encounter using JES3. Up to this
> point, we really haven't had an experienced JES3 person exercising
> the JES3 environment. I've been filling that role by default; I'm a
> retired JES2 system programmer who got fascinated by JES3. Whatever
> is broken, I probably had something to do with us. When you find
> something that doesn't work, or have a suggestion on how we could
> do it better, let us know. Hercules is a learning experience for
> all of us.

I wouldn't exactly call myself an expert. I was a PL/1 and COBOL application programmer with a small amount of assembler experience in a large JES3 shop, but being me, I couldn't help but delve a bit deeper into how the whole thing worked. I was the sort of child parents dread, always taking things apart to find out how they worked! As a result, I have a lot of theoretical knowledge, but not much in the way of hands on experience! I am very interested in getting this working right though and so I am planning to learn as much as I can in what little free time I've got.

"Playing with my toys", is what my other half calls it and there's always more important stuff to do!

> > I added a 3270 at 00C6 (the JES3 console as I knew from my
> > previous experience) and a 1403 at 030F (again I knew from
> > previous experience JES3 would look for it).
>
> We did, I think, pretty much decide that the JES3 display console
> is supposed to be at 014. The existing TK3 system didn't have a
> UCB there, so we ended up borrowing one of the VTAM 3277 addresses.
> The TK3 update system I'm looking at does have 014; if yours does,
> you could move the JES3 console from 0C6 to 014.
>
> Addresses for the MLOG printer and JES3 procedure "JES3OUT"
> printer have gotten moved around by non-JES3 requirements. I
> think I finally gave up trying to use the 30x range; in my personal
> JES3 system, I've moved MLOG to 31E and JES3OUT to 31F, but those
> assignments have never been implemented in the TK system and the
> TK3 update system I'm looking at doesn't have UCBs generated for
> those devices. Until that happens, 30F is probably going to have
> to do.
>
One of the things on my to do list is to examine the defined devices. I want to add more DASD and need to know where I can put them. 014 does seem like a better place for the JES3 console than up with the user terminals. If I find that 014 is defined correctly, I will move it. I'll have a look at the printer situation. It appears to me that in the TK3 update 31E is MLOG and 31F is JESOUT.

I have also noticed that there is one tape drive in the config file on 420, but JES3IN00 has tape devices declared at 400 thru 40F, so I need to check this out and amend accordingly.

> I don't know if you've gotten far enough to think about the
> possibilities of a multi-system JES3 complex. Unfortunately,
> right now Hercules CTC support isn't robust enough to meet JES3
> requirements. That's on the list of desirable features to add,
> and has been for a while. I have built a functional complex using
> guest machines under VM with JES3 global, JES3 local and ASP real
> main, so when Hercules supports it we can do it.

This is a big shame. It was my intention to run a complex with at least two mains. Is the problem with the CTC documented anywhere? Do we know if anyone is actively looking at it as part of the ongoing development?

Regards

Simon

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 12 Nov 2010 22:05
Picon
Favicon

Re: State of Turnkey

 



> saucyjacks wrote:

><snip>

> I have also noticed that there is one tape drive in the config file
> on 420, but JES3IN00 has tape devices declared at 400 thru 40F, so I
> need to check this out and amend accordingly.

Can't remember what is where now. Please advise as you explore.

><snip>

> This is a big shame. It was my intention to run a complex with at
> least two mains. Is the problem with the CTC documented anywhere?
> Do we know if anyone is actively looking at it as part of the
> ongoing development?

IIRC, the JES2 or JES3 source has perhaps the only documentation for how the CTC operates to connect two systems. I might be wrong. Don't believe there is anyone looking to add the functionality to Hercules at present. Could be wrong there also, am not a developer.

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Tony Harminc | 12 Nov 2010 22:59
Picon

Re: Re: State of Turnkey

 

On 12 November 2010 16:05, halfmeg <opplr-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:

>> saucyjacks wrote:

>> This is a big shame.  It was my intention to run a complex with at
>> least two mains.  Is the problem with the CTC documented anywhere?
>>  Do we know if anyone is actively looking at it as part of the
>> ongoing development?
>
> IIRC, the JES2 or JES3 source has perhaps the only documentation for how the CTC operates to connect two systems.  I might be wrong.  Don't believe there is anyone looking to add the functionality to Hercules at present.  Could be wrong there also, am not a developer.

Jumping in in the middle here...

CTC support just isn't there in Hercules in the general sense (uh, no
pun intended...) What support there is is for TCP/IP, and doesn't
cover the general case. If you want to have two systems talk to each
other via CTCs, you can do it by running them both under the same
instance of VM/370, and connecting them with virtual CTCs.

As for CTC doc via code, JES2 at the MVS 3.8 level does not support
CTCs, since no RJE terminal connected this way, and the NJE code that
used them was a Program Product add-on to JES2. You can see the
missing line number ranges where IBM effectively stripped out NJE
before shipping the base JES2. However, when stripping, they seem to
have left the low level CTC CCW setup and handling code in place in
HASPRTAM, and even a tiny bit of the initialization code in HASPINIT,
though there is no way to actually define an NJE connection. A search
on DCT flag DCTPCTC will help find this code.

But in any case the current IBM book Network Job Entry Formats and
Protocols, SA22-7539 provides a quite detailed description of the use
of CTCs for NJE, including normal and error recovery sequences.

I understand that JES3 used CTCs long before NJE was on the radar, and
certainly before JES3 supported the NJE protocols, so there may well
be code in there that provides further enlightenment.

Tony H.

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Kevin Leonard | 15 Nov 2010 04:05
Picon
Favicon

Re: State of Turnkey

 

Simon:

> I wouldn't exactly call myself an expert.

Remember, everything is relative.

> but being me, I couldn't help but delve a bit deeper into how the
> whole thing worked. I was the sort of child parents dread, always
> taking things apart to find out how they worked!

Did you have pieces left over when you tried to put things back
together? You'll feel right at home here. A lot of us are like
that.

> "Playing with my toys", is what my other half calls it and there's
> always more important stuff to do!

There'll always be more important stuff to do, if you let it happen
that way. Playing with your toys is cool.

> One of the things on my to do list is to examine the defined
> devices. I want to add more DASD and need to know where I can
> put them.

Phil can speak to this with more authority than I can, but I'll take
a shot at it. Historically, graphic devices and unit record devices
were on channel 0, DASD and more unit record devices were on channels
1, 2 and 3, tape on channel 4, CTC on channels 5 and 6. TK3 update
added more DASD on channels 7 and E, and graphic devices on channel D.
Other channels are currently unused.

DASD on channels 1-3 are split out by type:

x2x reserved for 2311
x3x 2314
x4x 3350
x5x 3330 and 3330-1
x6x 3340
x7x 3375
x8x once 3380, now reserved for VM CMS guest use
x9x once 3390, now reserved for VM CMS guest use
xAx 3380
xBx 3390
xDx reserved for 2305-2
xFx reserved for 2305-1

> 014 does seem like a better place for the JES3 console than up with
> the user terminals. If I find that 014 is defined correctly, I will
> move it.

014 and 016 are defined in the MVS starter system as 3158 displays.
That's what inspired those device numbers. The original TK3 system
didn't have JES3, and when I started working on adding it (originally
for TK4) I didn't know yet what I would like to see for consoles. As
a result, the separately-defined JES3 display console UCBs were an
afterthought.

> I'll have a look at the printer situation. It appears to me that
> in the TK3 update 31E is MLOG and 31F is JESOUT.

It does? I am not seeing printer UCBs for 31E and 31F. It would be
nice, though.

> I have also noticed that there is one tape drive in the config file
> on 420, but JES3IN00 has tape devices declared at 400 thru 40F, so
> I need to check this out and amend accordingly.

There are tape UCBs in the generated TK3UPD system at 400-40F:

d u,tape,offline
IEE450I 03.55.51 UNIT STATUS 369 C
UNIT TYPE UNIT TYPE UNIT TYPE UNIT TYPE UNIT TYPE UNIT TYPE UNIT TYPE
400 3400 401 3400 402 3400 403 3400 404 3400 405 3400 406 3400
407 3400 408 3400 409 3400 40A 3400 40B 3400 40C 3400 40D 3400
40E 3400 40F 3400

JES3 would complain about split generics if the inish deck definitions
didn't match the actual EDT values, and it doesn't. That why there
are so many printers defined to JES3: not because they are ever
going to be used, but to prevent the split-generic error.

> > I don't know if you've gotten far enough to think about the
> > possibilities of a multi-system JES3 complex. Unfortunately,
> > right now Hercules CTC support isn't robust enough to meet JES3
> > requirements. [...]
>
> This is a big shame. It was my intention to run a complex with
> at least two mains. Is the problem with the CTC documented
> anywhere? Do we know if anyone is actively looking at it as
> part of the ongoing development?

The problem with existing Hercules CTC support is that what's
there was written to be the basis for TCP/IP interface devices,
not as a complete 3088 implementation. Fully functional bidirectional
CTC support would require intelligence to manage both ends of the
conversation, maintain status and handle dependent requests. It's
been discussed in development circles from time to time, but nothing
concrete has happened so far. I haven't given up.

--

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
saucyjacks-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org | 15 Nov 2010 12:22
Favicon

Re: State of Turnkey

 

Hi Kevin

> Phil can speak to this with more authority than I can, but I'll take
> a shot at it. Historically, graphic devices and unit record devices
> were on channel 0, DASD and more unit record devices were on channels
> 1, 2 and 3, tape on channel 4, CTC on channels 5 and 6. TK3 update
> added more DASD on channels 7 and E, and graphic devices on channel D.
> Other channels are currently unused.
>
> DASD on channels 1-3 are split out by type:
>
> x2x reserved for 2311
> x3x 2314
> x4x 3350
> x5x 3330 and 3330-1
> x6x 3340
> x7x 3375
> x8x once 3380, now reserved for VM CMS guest use
> x9x once 3390, now reserved for VM CMS guest use
> xAx 3380
> xBx 3390
> xDx reserved for 2305-2
> xFx reserved for 2305-1

I had a look at the sysgen configuration in the files section of this group and that pretty much seems to tie up with what you have said here. I am a little confused by the definitions for the 2701, 2703 and 3705 devices, but I'm sure some research will make it all clear!

There are plenty of spare DASD devices defined for my needs. I will probably go with a number of 3390s. Not historically accurate, but since the capability is there... :) I adjusted JES3IN00 to put the console JES3 console on 014 and everything is fine. JES3 is now my default JES and I have BSPPILOT, BSPSETUP, VTAM and TSO running automagically after startup. I briefly broke everything over the weekend by a misguided attempt to increase the number of VTAM users and running processes, but I managed to recover fairly easily.

I am having problems bringing writers. Entering

*X CR,IN=00C,K

results in a hot reader being available and pointing 00C at a job deck using devinit in Hercules results in the job being entered into the system. Entering

*X WTR,OUT=00E

however results in messages about device 00E not being available and the WTR command being cancelled. Device 00E is there in both the sysgen and the tk3upd.conf file and is defined as a printer in both, so I don't really understand what's going on!

> > I'll have a look at the printer situation. It appears to me that
> > in the TK3 update 31E is MLOG and 31F is JESOUT.
>
> It does? I am not seeing printer UCBs for 31E and 31F. It would be
> nice, though.
>
Sorry, my mistake. I think that should have been 30E and 30F!

> > I have also noticed that there is one tape drive in the config file
> > on 420, but JES3IN00 has tape devices declared at 400 thru 40F, so
> > I need to check this out and amend accordingly.
>
> There are tape UCBs in the generated TK3UPD system at 400-40F:
>

My fault again. I didn't have my system to hand when composing the message. The tape drive in the standard tk3upd.conf is on 400. I have added 401-40F now, mainly because I'm greedy! I always used to hate having to wait for tape units to become available when I was running development jobs and there was never enough DASD to go around!

> > > I don't know if you've gotten far enough to think about the
> > > possibilities of a multi-system JES3 complex. Unfortunately,
> > > right now Hercules CTC support isn't robust enough to meet JES3
> > > requirements. [...]
> >
> > This is a big shame. It was my intention to run a complex with
> > at least two mains. Is the problem with the CTC documented
> > anywhere? Do we know if anyone is actively looking at it as
> > part of the ongoing development?
>
> The problem with existing Hercules CTC support is that what's
> there was written to be the basis for TCP/IP interface devices,
> not as a complete 3088 implementation. Fully functional bidirectional
> CTC support would require intelligence to manage both ends of the
> conversation, maintain status and handle dependent requests. It's
> been discussed in development circles from time to time, but nothing
> concrete has happened so far. I haven't given up.

I may be able to have a look at this at some point. I'll have to have a trawl through the bitsavers archive and see what documentation is available. I expect it would be too much to ask that a POO type document for the 3088 is there!

Regards

Simon

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Tony Harminc | 16 Nov 2010 01:15
Picon

Re: Re: State of Turnkey

 

On 15 November 2010 06:22, saucyjacks-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org <saucyjacks-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org> wrote:

> I may be able to have a look at this at some point.  I'll have to have a trawl through the bitsavers archive and see what documentation is available.  I expect it would be too much to ask that a POO type document for the 3088 is there!

Whether it's at bitsavers or not, it's available from IBM. What you
want is the Channel-to-Channel Adapter for the System/360 and
System/370 I/O Interface, SA22-7091. There is also an ESCON version,
SA22-7203. If you have trouble finding these, I have them in .boo
format.

These books have a lot of detail, but I still recommend the NJE
Formats and Protocols book for how they are actually used by JES2,
JES3, RSCS, and VSE/POWER.

Tony H.

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Gregg C Levine | 16 Nov 2010 03:58
Picon
Favicon

RE: Re: State of Turnkey

Hello!
Tony I don't know if our friend will need them or not, but could you make
them available? You can either send them to me directly, (Which would be
best, or park them on the main MVS group's folder tree. In which case I'll
dismount them, and advise you that they've been so removed.)

I believe I have both of the ones on the OEM concept, but that pair I
believe not.......
---
Gregg C Levine hansolofalcon@...
“This signature is not the same one. Move along! Move along!”

> -----Original Message-----
> From: turnkey-mvs@...
[mailto:turnkey-mvs@...] On
> Behalf Of Tony Harminc
> Sent: Monday, November 15, 2010 7:16 PM
> To: turnkey-mvs@...
> Subject: Re: [turnkey-mvs] Re: State of Turnkey
> 
> On 15 November 2010 06:22, saucyjacks@... <saucyjacks@...>
> wrote:
> 
> > I may be able to have a look at this at some point.  I'll have to have a
trawl through
> the bitsavers archive and see what documentation is available.  I expect
it would be
> too much to ask that a POO type document for the 3088 is there!
> 
> Whether it's at bitsavers or not, it's available from IBM. What you
> want is the Channel-to-Channel Adapter for the System/360 and
> System/370 I/O Interface, SA22-7091. There is also an ESCON version,
> SA22-7203. If you have trouble finding these, I have them in .boo
> format.
> 
> These books have a lot of detail, but I still recommend the NJE
> Formats and Protocols book for how they are actually used by JES2,
> JES3, RSCS, and VSE/POWER.
> 
> Tony H.
> ------------------------------------

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/turnkey-mvs/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/turnkey-mvs/join
    (Yahoo! ID required)

<*> To change settings via email:
    turnkey-mvs-digest@... 
    turnkey-mvs-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    turnkey-mvs-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
saucyjacks-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org | 16 Nov 2010 14:16
Favicon

Re: State of Turnkey

 

--- In turnkey-mvs <at> yahoogroups.com, Tony Harminc <tharminc <at> ...> wrote:
>
> On 15 November 2010 06:22, saucyjacks <at> ... <saucyjacks <at> ...> wrote:
>
> > I may be able to have a look at this at some point.  I'll have to have a trawl through the bitsavers archive and see what documentation is available.  I expect it would be too much to ask that a POO type document for the 3088 is there!
>
> Whether it's at bitsavers or not, it's available from IBM. What you
> want is the Channel-to-Channel Adapter for the System/360 and
> System/370 I/O Interface, SA22-7091. There is also an ESCON version,
> SA22-7203. If you have trouble finding these, I have them in .boo
> format.
>
> These books have a lot of detail, but I still recommend the NJE
> Formats and Protocols book for how they are actually used by JES2,
> JES3, RSCS, and VSE/POWER.
>
Thanks for that Tony, I have found the ESCON version of the CTCA manual and the NJE Formats and Protocols book. I will need both of these if I am to make any progress! Now all I have to do is see if I can understand the Hercules architecture. If and when I think I can implement anything I will run the proposed solution past the H390 group for comment. I hope I'm not biting off more than I can chew here!

Regards

Simon

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 16 Nov 2010 15:14
Picon
Favicon

Re: State of Turnkey

 

> saucyjacks wrote:

><snip>

> I am a little confused by the definitions for the 2701, 2703 and
> 3705 devices, but I'm sure some research will make it all clear!

Another late edition to Turnkey is Max's work on this. His web pages will probably help understanding about these.

http://www.lightlink.com/mhp/2703/

http://www.lightlink.com/mhp/3705/

><snip>

> I am having problems bringing writers. Entering

> *X CR,IN=00C,K

> results in a hot reader being available and pointing 00C at a job
> deck using devinit in Hercules results in the job being entered into
> the system. Entering

> *X WTR,OUT=00E

> however results in messages about device 00E not being available and
> the WTR command being cancelled. Device 00E is there in both the
> sysgen and the tk3upd.conf file and is defined as a printer in both,
> so I don't really understand what's going on!

It's already allocated ( as a wtr (?) )

*i d,d=00e

><snip>

*i d,n=all

might be good to take a look at also.

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Kevin Leonard | 17 Nov 2010 02:32
Picon
Favicon

Re: State of Turnkey

 

Simon:

> I am having problems bringing writers. Entering
>
> *X CR,IN=00C,K
>
> results in a hot reader being available and pointing 00C at a
> job deck using devinit in Hercules results in the job being
> entered into the system. Entering
>
> *X WTR,OUT=00E
>
> however results in messages about device 00E not being available
> and the WTR command being cancelled. Device 00E is there in both
> the sysgen and the tk3upd.conf file and is defined as a printer
> in both, so I don't really understand what's going on!

My first thought was that you've been caught up in the confusion
around printer device numbers (JES3OUT in the current JES3 proc
is defined as 00E), but I don't think that's it. I'm guessing
that somehow, 00E is offline to JES3, but I don't know how that
might have happened. What do you get when you issue the commands:

d u,,,00e,1

and

*i,d,d=00e

Looking at JES3 printer definitions, I did find another problem.
DEVICE statements for both 20E and 20F have the same JNAME, PR20F.

If I'm understanding it correctly, *VARY (or *MODIFY,V) changes the
XUNIT availability of a device, but it doesn't affect the JUNIT
availability, and I think that's what getting checked by the WTR.
Here's a case where I could definitely benefit from actual JES3
experience.

> I expect it would be too much to ask that a POO type document for
> the 3088 is there!

The 3088 hardware manual is SA22-7091 Channel-to-Channel Adapter
for the System/360 and System/370 I/O Interface. Last I checked,
bitsavers doesn't have it. I have a Bookmanager format copy
somewhere if that would help.

--
Kevin

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
saucyjacks-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org | 19 Nov 2010 12:52
Favicon

Re: State of Turnkey

 

I was trying to set up an exploratory environment last night in preperation for getting into the CTC code to get my mulitple main JES3 complex set up when I came across what I believe to be an issue with the TK3 update and it's implementation of JES3.

Most of the JES3 system stuff resides on 3 3350s on devices in the 7xx range. This includes the JES3 spool volume. In any multiple main JES3 complex, these volumes would need to be shared and the 7xx range of devices are not defined as shared DASD.

This ought to be addressed before TK4 is released as it makes having JES3 in the build of limited value. For the time being, can I just move the volumes onto shared devices? Will I need to change any SYS1.PARMLIB members or similar if I do?

Regards

Simon

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 19 Nov 2010 13:47
Picon
Favicon

Re: State of Turnkey

 

> saucyjacks wrote:

> I was trying to set up an exploratory environment last night in
> preperation for getting into the CTC code to get my mulitple main
> JES3 complex set up when I came across what I believe to be an issue
> with the TK3 update and it's implementation of JES3.

Very possible.

> Most of the JES3 system stuff resides on 3 3350s on devices in the
> 7xx range. This includes the JES3 spool volume. In any multiple
> main JES3 complex, these volumes would need to be shared and the 7xx
> range of devices are not defined as shared DASD.

Right, when they were added we hadn't regenned the I/O configuration and just placed them over in the 700 address range.

> This ought to be addressed before TK4 is released as it makes having
> JES3 in the build of limited value. For the time being, can I just
> move the volumes onto shared devices? Will I need to change any
> SYS1.PARMLIB members or similar if I do?

You should be able to change the Hercules configuration file as to which address they are mounted on. I can't remember any other place where the device address is hard-coded in the system.

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 12 Nov 2010 00:43
Picon
Favicon

Re: State of Turnkey

 

> Simon Williams wrote:

> Okay, busy night last night and this morning, but I have reinstalled
> the Turnkey 3 Update and am happy to report that everything is
> looking a lot healthier than after my first attempt!

Great! Good to hear.

><snip>

> This time, JES3 came up, in that the console sprang to life, but I
> couldn't start JSS. ReIPL'd back into JES2 and did some
> investigation. Nothing seemed to be awry, so I tried again. This
> time it ABENDed U0004 telling me there were catastrophic errors
> during initialisation. It was after midnight, so I went to bed to
> sulk!

Been there myself at times. :-)

> This morning I thought I'd have one more go while I ate breakfast.

> Processor spin! I'd almost forgotten about that. I'd been bringing
> the system up and down without that problem ever since the
> re-install!

> Then it struck me. That message buried in the logs that I had
> ignored about not recognising CPU 001006688 (or something, I can't
> remember the exact number off the top of my head). Into the
> configuration, NUMCPU=1, saved it restarted hercules, r 00,sysp=j3,
> JES3 cold start, *s jss, start VTAM, start TSO and everything is
> working!!! I put the network and TSO startup into COMMNDJ3 and it
> still came up as expected.

I must confess, I haven't attempted to run with CPU=2 but others have. It seems intermittent from the posts, but it would be good to nail down. You stated your initial TK3 build from scratch worked with CPU=2 in hercules config ?

> I was late for work!

Will they understand ?

> Tonight, make JES3 the default system, have a play with the 3705
> stuff and find a decent JES3 Cheat Sheet as I was never an expert
> and my memory isn't what it was!

When I get 'some time' I may have some JES3 reference material but am not sure.

> Life is good in geek heaven!

When stuff works it is for sure.

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 28 Nov 2010 18:23
Picon
Favicon

Re: State of Turnkey

 

> Simon Williams wrote:

><snip>

> This time, JES3 came up, in that the console sprang to life, but I
> couldn't start JSS. ReIPL'd back into JES2 and did some
> investigation. Nothing seemed to be awry, so I tried again. This
> time it ABENDed U0004 telling me there were catastrophic errors
> during initialisation. It was after midnight, so I went to bed to
> sulk!

> This morning I thought I'd have one more go while I ate breakfast.

> Processor spin! I'd almost forgotten about that. I'd been bringing
> the system up and down without that problem ever since the
> re-install!

> Then it struck me. That message buried in the logs that I had
> ignored about not recognising CPU 001006688 (or something, I can't
> remember the exact number off the top of my head). Into the
> configuration, NUMCPU=1, saved it restarted
> hercules, r 00,sysp=j3, JES3 cold start, *s jss, start VTAM, start
> TSO and everything is working!!! I put the network and TSO startup
> into COMMNDJ3 and it still came up as expected.

Don't remember if you have a single processor host or multi-processor host. From your other posts think you may be running a LINUX host.

Would like to nail down the problem of the spin and your experience above may give a hard fail to pin point the issue(s).

Just wanting to be sure on what type of environment to test on.

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
saucyjacks-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org | 11 Nov 2010 15:38
Favicon

Re: State of Turnkey

 

<--snip-->

> logged in to TSO and RPF worked fine (still got two ABENDs on my first log in,
> but it all worked afterwards and got no ABENDs on subsequent logins.

I was wondering, those ABENDs weren't notifys for HERC01 left undelivered in the system by something running just prior to the snapshot being taken?

Just a thought!

Regards
 
Simon

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
halfmeg | 12 Nov 2010 00:46
Picon
Favicon

Re: State of Turnkey

 

> saucyjacks wrote:

><snip>

> I was wondering, those ABENDs weren't notifys for HERC01 left
> undelivered in the system by something running just prior to the
> snapshot being taken?

> Just a thought!

You may find completion messages for a few of the IDs. Someone chastised me for not clearing the broadcast dataset. Just getting something out in case I couldn't work on it any more was more important than fixing and polishing.

Phil

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
saucyjacks-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org | 12 Nov 2010 10:38
Favicon

Re: State of Turnkey

 



--- In turnkey-mvs-hHKSG33TihhbjbujkaE4pw@public.gmane.org, "halfmeg" <opplr <at> ...> wrote:
>
> > saucyjacks wrote:
>
> ><snip>
>
> > I was wondering, those ABENDs weren't notifys for HERC01 left
> > undelivered in the system by something running just prior to the
> > snapshot being taken?
>
> > Just a thought!
>
> You may find completion messages for a few of the IDs. Someone chastised me for not clearing the broadcast dataset. Just getting something out in case I couldn't work on it any more was more important than fixing and polishing.

Not a problem, just one less thing to worry about! :)

Regards

Simon

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |

Gmane