• New Members 2

• New Members 2

> Harold Bell wrote:

> Are there any changes to scsi tape in tk3upd I should be aware of?

No. To my knowledge there were no modifications which impact tape at all in TK3, TK3SU1 or TK3UPD.

> I am following the same procedure with tk3upd as I did when running
> tk3 when writing tape but when I use

> "devinit 400 /dev/nst0 --blkid-24"

> at the hercules console the herc instcnt freezes and I have to close
> the terminal window in which it is running. Thanks for the help.

> Buddy

If the above worked with plain TK3, it should work with TK3UPD.

The 1st place I would look is to see if a different Hercules version is being executed as the SCSI tape handling is there.

You may also wish to change blkid-24 to blkid-22 as some code in tapedev.c, "Query the device definition", only checks values of blkid-32 and blkid-22 ( recent SVN, Oct 2010 ).

Phil

• New Members 2

I've posted another KICKS KooKbooK recipe, #11, "Designing and implementing simple KICKS GCCMVS programs". The recipe index page is http://home.gci.net/~mike-noel/KICKS/KooKbooK.htm

• New Members 2

> 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?

> 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 parmlib 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.

> 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.

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.

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.

> 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.

> 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 ?

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

> 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.

> 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.

> <WARNING> (and off-topic,

><snip>

> 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, there 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.

> For me at least, this is all a step in the right direction, I have a
> usable JES3. I will continue to look at it and see if I can sort
> out any of the problems, but if anyone has any ideas I would be
> grateful.

Please post your experiences and suggestions. TK3UPD is still considered ALPHA, BETA or FINAL depending upon what an individual's usage may be. When I get through playing with SORT and court issues, my intention is to return to it for a final distribution.

After that TK4 proper will start with a new base install as there is a problem with some PTFs in TK3.

> One small point I feel I need to make is that I have seen in a
> number of places people claiming that '*' and '8' are
> interchangeable as command prefixes in JES3. They are NOT. it is
> just that the difference doesn't matter in a single main jesplex.
> '*' prefixes a global command, to be sent to all mains in the
> jesplex and '8' prefixes a local command that is processed by the
> local main only. Not wishing to be pedantic, but I am hoping one
> day to get into the position where this DOES matter to me and
> hopefully others as well!

That would probably be me. Due to my experience with JES3. We had 2 JES3 images running in the shop. Both were Global IIRC. We later moved to JES2 on both.

> Lastly, could anyone tell me where I can find the system definitions
> used in the sysgen for the Turnkey 3 update. As detailed above, I
> have a number of non-standard devices defined to my old Turnkey
> system and need to find sensible device addresses for them on the
> updated system. Without the sysgen details, I don't know what
> device addresses have been defined as what devices.

In the files section:

TK3CFG3.txt - TK3 Update Configuration - BETA

Phil

• New Members 3

• New Members 3

> 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

• New Members 3

• New Members 3

I've posted another KICKS KooKbooK recipe, #12, "Using Alternate 3270 screen sizes in COBOL and GCCMVS programs". The recipe index page is
http://home.gci.net/~mike-noel/KICKS/KooKbooK.htm

• New Members 3