I have uploaded the TK3SU1.zip file again. It should stay online this
time around until I get another update out the door.

You can download it currently from:

www.classiccmp.org/softlib/TK4Beta

Softlib is moving and classiccmp has graciously allowed us to be
hosted there. The softlib link will be redirected after I finish
uploading the rest of the old site to the new location.

Phil - original post replied to as I have forgotten everything we did
in the shadow update

There is a fixpack1.zip file as well which should be run after the
TK3SU1.zip is applied to correct a few minor/major glitches. It is
also found at the above link.

Good Luck all:

> halfmeg wrote:
>
> We have been working a little recently to bring you a fairly large
> update to the MVS TK3 system. The list of things included are
> numerous:
>
> All of the items 1 - 32 at:
>
> www.bsp-gmbh.com/turnkey/tk4wish.html
>
> with updates of RPF and IND$FILE to even more recent versions and a
> bug fix for the XMIT/RECV package.
>
> I believe that 2, 5*, 6, & 7 on the still to-do list are also done.
> ( * JES3 is a very recent addition and currently is on the same
> sysres as JES2 ).
>
> As with a lot of things, some small things slip through the cracks.
> I forgot to include a README in the update zip file itself. One of
> the testers reported a need to specify a REGION statement on jobs
> submitted under JES3 as I didn't increase the default from 52K or
> so.
>
> So without further ramblings, you can obtain the update zip file at:
>
> www.box.net/public/at0xixe608#main < no longer valid <<<<----<<<<<
>
> It is slightly less than 63 Mb.
>
> It should be applied to a fresh or clean install of the TK3 base
> system. You don't have to have all the packs installed. If you
> selected to leave the CBT, SRC, SMP and starter system packs
> uninstalled, this update should still work with your MVS
> environment.
>
> So the procedure would be.
>
> 1. Clean install of TK3.
> 2. Unzip of TK3SU1.zip into the directory where TK3 was installed
> ie c:\mvs38j or similiar
>
> At this point a new config file ( TK3SU.conf ) will be placed in
> your config directory which will need to be used for hercules
> startup. If you start Hercules with the line commands it would be
> something like:
>
> hercules -f conf\tk3su.conf
>
> New DASD base files for the added packs like DLIxxx and JSxxxx will
> be added to the DASD directory and the bulk of the data will be
> added to the SHADOW directory as shadow disk files.
>
> For routine operation of JES2, the startup is identical to 1st time
> TK3 startup I believe.
>
> 3. Start hercules
> 4. Connect your 3270 client and telnet client as you would normally
> 5. IPL 148
> 6. to IEA101 message reply R 0,CLPA
> 7. JES2 will terminate due to unformatted spool and checkpoint
> 8. S JES2, reply 'r x,cold,format'
> 9. $S when it asks you to enter requests
> 10. The system should be up and running at this point with all the
> new stuff ready to use.
>
> Now for those who want to experiment a little. You can run the
> updated system with a security package. You have a choice of 2
> different ones, RAKF or PIES. This is currently only available with
> the JES2 environment and has to be selected at IPL time. When the
> IEA101 message appears, reply, 'r 0,sysp=PI' for PIES or
> 'r 0,sysp=RA' for RAKF.
>
> For the even more adventurous, you can experiment with JES3. At IPL
> time when presented with the IEA101 message, reply r 0,sysp=j3 and
> you will soon see some different messages and required responses to
> bring JES3 up and running.
>
> IAT3011 SPECIFY JES3 START TYPE
> *00 IAT3011 (L H HA W WA OR C)
> give this a r 0,C
>
> *01 IAT3033 CONFIRM JES3 COLDSTART REQUEST (U)
> and a r 1,U
>
> *02 IAT3012 SELECT JES3 INISH ORIGIN (N M= OR U=), AND OPTIONAL EXIT
> PARM (,P=)
> and a r 2,N
>
> then this shows up
> 0142007 IAT3100 JES3 3.0.0 SYSTEM COLDSTART ON 6.337 AS SY1
> enter *s jss
>
> An important note here, we haven't configured any JES3 consoles in
> the system ( remember very recent addition ) so the telnet console (
> formerly 009 now moved to 01F ) is your main console for JES3 as
> delivered currently.
>
> You can start the card reader and output printer.
>
> *x cr,in=00c,k
>
> *x wtr,out=00e
> 8s 00e
>
> * & 8 are interchangable in the JES3 command systax for 1st
> character
>
> You are now ready to run a job, but not to logon on TSO. Why you
> may ask. Because of that other twist of fate. I didn't add all
> the start up commands that the JES2 side already has in place. If
> you want to run under JES3 and log on to TSO , just enter 's net' &
> 's tso'. Your 3270 client tso terminal should be ready for you to
> logon. This should also help to remind you that the JES3 stuff is
> a work in progress.
>
> How do I shut this beast down. Ok, if you have started up TSO,
> enter 'p tso' followed by a 'U' to the reply that appears. Then
> enter 'z net,quick' to shutdown VTAM. Enter 'P CMD1' to stop CMD1
> and finally you enter '8return' to shutdown JES3. You can now
> 'power off' Hercules.
>
> If it all works, it's the effort of many people, if it's broken,
> blame me.
>
> Phil - a space blanket, that's what I need - they'll never find me
> in space

•  2
  New Members

Thank you

•  2
  New Members

> James Huckert wrote:

> Thank you

> > halfmeg wrote:
> >
> > I have uploaded the TK3SU1.zip file again.

><snip>

Perhaps I should have waited a little longer before posting. It is
still uploading.

Phil - there must be molasses in my DSL this morning - another 10 mins
should do it

•  2
  New Members

I am using GCCMVS 3.0 with PDPCLIB 0.84 (under MUSIC/SP,
but I think the same problem must occur under MVS 3.8
and CMS) to run a C program that works fine with MinGW C.
The C prog has several global variables which are declared
"static" (therefore local to the file, and the names do
not appear in the object file). The problem is that the
GCCMVS compiler (gccmvs.exe run on Win32) truncates the
names to 8 chars, errors "name has been previously defined"
occur during assembly (with IFOX00 assembler), and the
program does not run correctly. It should be possible for
the compiler to use internal short names, so that errors
do not occur at assembly time.

Does anyone know of a compiler option or similar that
avoids this problem? Is anyone planning to fix it?

For now, a work-around is to move the global variables
into a structure, and use a short name for the structure.
Then the names inside the structure can be any length.
For example:

struct gsstruct
{ int globalvar1;
int globalvar2;
};
static struct gsstruct gs1,*gs;

int main(void)
{
gs=&gs1; /* pointer to structure */
gs->globalvar1=123;
gs->globalvar2=456;
/* ... */
return 0;
}

Also, does anyone know how to specify a larger stack size?
The default size seems to be 128K (?). I have a program
that needs more, maybe 1MB, because it uses recursive
functions. If the stack is exceeded, the program just stops
with no error message!

While I'm asking, documentation on stack size for MinGW C is
hard to find. Does anyone know how to control the stack in
MinGW and what the default size is? From experimenting, it
seems to be about 1MB (?)

- Dave Edwards

•  1
  New Members

•  1
  New Members

--- In turnkey-mvs <at> yahoogroups.com, "dave5550" <dave5550 <at> ...> wrote:
>
> I am using GCCMVS 3.0 with PDPCLIB 0.84 (under MUSIC/SP,
> but I think the same problem must occur under MVS 3.8
> and CMS) to run a C program that works fine with MinGW C.
> The C prog has several global variables which are declared
> "static" (therefore local to the file, and the names do
> not appear in the object file). The problem is that the
> GCCMVS compiler (gccmvs.exe run on Win32) truncates the
> names to 8 chars, errors "name has been previously defined"
> occur during assembly (with IFOX00 assembler), and the
> program does not run correctly. It should be possible for
> the compiler to use internal short names, so that errors
> do not occur at assembly time.

Yes it should. Issue 9 in gccmvs.txt says that that is a problem
and that internal names should instead be generated as <at> <at> F1234
or similar.

> Does anyone know of a compiler option or similar that
> avoids this problem?

Well, you can overcome the problem by defining one of the
global variables to a new name via a compile option.

> Is anyone planning to fix it?

I haven't seen anyone volunteer to do that.

> For now, a work-around is to move the global variables
> into a structure, and use a short name for the structure.
> Then the names inside the structure can be any length.
> For example:
>
> struct gsstruct
> { int globalvar1;
> int globalvar2;
> };
> static struct gsstruct gs1,*gs;
>
> int main(void)
> {
> gs=&gs1; /* pointer to structure */
> gs->globalvar1=123;
> gs->globalvar2=456;
> /* ... */
> return 0;
> }

Yuck.

Why not just include an include file that does:

#define globalvar1 gvar1
#define globalvar2 gvar2

That is what mshort.h is for in config/i370. We obviously had
this same problem for compiling gcc itself. All static functions
and static variables needed to be 8-character unique.

I didn't have the skills required to fix the problem properly,
but did have the skills to create mshort.h.

> Also, does anyone know how to specify a larger stack size?
> The default size seems to be 128K (?). I have a program
> that needs more, maybe 1MB, because it uses recursive
> functions.

You need to change the MAINSTK variable in mvsstart.asm, which
is currently set to 32000 * 4 = 128K.

> If the stack is exceeded, the program just stops
> with no error message!

Anything at all can happen after a stack overflow.

> While I'm asking, documentation on stack size for MinGW C is
> hard to find. Does anyone know how to control the stack in
> MinGW and what the default size is? From experimenting, it
> seems to be about 1MB (?)

I don't know about that.

BFN. Paul.

•  1
  New Members

--- In turnkey-mvs <at> yahoogroups.com, "kerravon86" <kerravon86 <at> ...> wrote:
>
>... snip snip
>

The solution would be ( I am investigating it ) to adapt the path followed
when the LONGEXTERNAL ( for 3.4.6 ) is defined

I guess that the equvalent for 3.2.3 is TARGET.ALIAS

also the same approach might be used for upper/lower case,
it would be foolish to have let' s say both "ini m" and "int M",
but who knows ...

I have been playing introducing a new pragma
"#pragma alias(lonvarname,shortvar)

and it seems to work for both cases

regards

enrico sorichetti

PS. here is how it looks like

******** the source
// tvars.c
//

#pragma alias(longvarname1,lvar1)
#pragma alias(longvarname2,lvar2)

char longvarname1[] = "a" ;
char longvarname2[] = "b" ;

#pragma alias(i,ilow)
int i = 1;
int I = 2;

int main()
{
return 0 ;
}

******** the assembler
CSECT
ENTRY LVAR1
* Program data area
LVAR1 EQU *
DC C'a'
DC X'0'
ENTRY LVAR2
LVAR2 EQU *
DC C'b'
DC X'0'
ENTRY ILOW
DS 0F
ILOW EQU *
DC F'1'
ENTRY I
DS 0F
I EQU *
DC F'2'
* Program text area
DS 0F
ENTRY GCCMAIN
DS 0F
GCCMAIN CSECT
* Function gccmain prologue
EDCPRLG USRDSAL=28,BASEREG=3
PG0 EQU *
LR 11,1
L 4,=A(PGT0)
* Function gccmain code
SLR R0,R0
LR R15,R0
* Function gccmain epilogue
EDCEPIL
* Function gccmain literal pool
DS 0F
LTORG
* Function gccmain page table
DS 0F
PGT0 EQU *
DC A(PG0)
END

•  3
  New Members

--- In turnkey-mvs <at> yahoogroups.com, "halfmeg" <opplr <at> ...> wrote:
>
> > W.Philippi wrote:
> > Hi,
> > i have downloaded the Bwbasic Interpreter as a xmi File.
> ><snip>
>
> If it's from the Dignus site, it has a couple of problems on 3.8j
>
> 1. The module is linked 31 ANY.
> 2. It requires a Dignus C library at runtime.
>
> Phil - hair today - gone tomorrow
>
I relinked BWBASIC under MVS 3.8j (24 bit mode). This should have
"lost" the XA 31 bit addressing. I think that the code has some XA
dependencies in it since it abends with S0C4.
Ed

•  4
  New Members

--- In turnkey-mvs <at> yahoogroups.com, "Enrico Sorichetti"
<e.sorichetti <at> ...> wrote:
> The solution would be ( I am investigating it ) to adapt the path
followed
> when the LONGEXTERNAL ( for 3.4.6 ) is defined
>
> I guess that the equvalent for 3.2.3 is TARGET.ALIAS

The problem is not with external names. External names are
required by the C standard to be unique in the first 6
characters, and not case-sensitive. I have no problem
redefining them in mshort.h, as that is actually doing it
properly. Although I only made them 8-character unique
because I don't think the code will ever be on a 6-character
environment.

The problem is with static variables and functions, which
shouldn't be (and aren't) externally visible. They are getting
duplicate names in the assembly file.

It would certainly be good to have this problem solved.

BFN. Paul.

•  4
  New Members

--- In turnkey-mvs <at> yahoogroups.com, "kerravon86" <kerravon86 <at> ...> wrote:
>
> The problem is not with external names. External names are
> It would certainly be good to have this problem solved.
>
> BFN. Paul.
>

I was not talking about external names, but about approaching
the problem with the same method

testing 3.4.6 and defining LONGEXTERNALS I got the desired result

keeping the name short and distinguish between upper and lower case
now I have to force the use of the aliasing also for the short names
( just for the upper/lower case problem -
distinguish between "char aaa[]" and "char AAA[]")

here is the result

source c program
****************
// tvars.c
//
static int longintvar1 = 1 ;
static int LONGINTVAR1 = 11 ;
static int longintvar2 = 1 ;
static int LONGINTVAR2 = 22 ;
int main()
^^^ {
^^^^^^^^return 0;
^^^^}

assembler text
****************
^^^^CSECT
* Program data area
^^^^DS 0F
LO377204 EQU *
^^^^DC F'1'
^^^^DS 0F
LO721347 EQU *
^^^^DC F'11'
^^^^DS 0F
LO377205 EQU *
^^^^DC F'1'
^^^^DS 0F
LO721348 EQU *
^^^^DC F'22'
* Program text area
^^^^DS 0F
^^^^ENTRY GCCMAIN
^^^^DS 0F
GCCMAIN CSECT
* Function gccmain prologue
^^^^EDCPRLG USRDSAL=28,BASEREG=3
PG0 EQU *
^^^^LR 11,1
^^^^L 4,=A(PGT0)
* Function gccmain code
^^^^SLR R0,R0
^^^^LR R15,R0
* Function gccmain epilogue
^^^^EDCEPIL
* Function gccmain literal pool
^^^^DS 0F
^^^^LTORG
* Function gccmain page table
^^^^DS 0F
PGT0 EQU *
^^^^DC A(PG0)
^^^^END

regards

enrico s

•  4
  New Members