Manual installation of VACPP v3.08

[John Small]

I am looking into setting up VACPP v3.08. I had this installed on a
previous computer and I still have the VACPP files from the
installation on that system.

Hoping to avoid re-installing from scratch (including the various
patches), I'm wondering if it is possible to just copy the files and
set the relevant environment variables to get a functional VACPP.

I undersand that a) no objects will be created; b) no asscoiations
will be created; and c) the Workframe portion will not work since it
requires creating various WPS object classes. But other than this are
there reasons to think that just copying files and setting variables
would not work?

--

John Small
(remove z's for email)

[Marcel Müller]

Test it! No one can say exactly which components of VACPP depends on
further registrations. Maybe the debugger works, maybe only mostly, and
so on. Note that files might be placed in system directories by the
installer as well.

What you can do is, install VACPP 3 normally and then replace the files
with patch 3.08. This will work.


Marcel

[Steven Levine]

On Tue, 25 Sep 2012 15:45:12 UTC, "John Small" <jsm...@os2world.net>
wrote:

Hi John,

> Hoping to avoid re-installing from scratch (including the various
> patches), I'm wondering if it is possible to just copy the files and
> set the relevant environment variables to get a functional VACPP.

As Marcel suggested, try it. Without the WPS bits, VAC is just
another command line compiler toolchain.

FWIW, it's possible to get everything working, including the WPS bits,
but that takes some planning and the right tools. What I used was
Object Desktop's Object Packager to create a package that could be
moved to the other system. Restoring the package also registered all
the WPS classes.

Steve

--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------

[Andy]

On Tue, 25 Sep 2012 15:45:12 UTC, "John Small" <jsm...@os2world.net>
wrote:

I've been doing it for years since my CD became unreadable. I did not
really ever use the icons that were created and just used the command
line functions so I did not even try to bring them across so can't say
about those but both 3.08 and 3.65 have been copied across and I just
use the setup scripts (no config.sys changes for it here).
Andy
--

[Alex Taylor]

On Tue, 25 Sep 2012 15:45:12 UTC, "John Small" <jsm...@os2world.net> wrote:

> I am looking into setting up VACPP v3.08. I had this installed on a
> previous computer and I still have the VACPP files from the
> installation on that system.
>
> Hoping to avoid re-installing from scratch (including the various
> patches), I'm wondering if it is possible to just copy the files and
> set the relevant environment variables to get a functional VACPP.

Sure. I did that; I got the desktop stuff working too, actually,
with a little prior planning.

Update CONFIG.SYS with the following, replacing E:\Development\IBMCPP
with the correct path. (Watch out for extraneous line breaks in this
post.)

-------8<--------8<--------8<--------8<--------8<--------8<-------
DEVICE=E:\Development\IBMCPP\SYS\CPPOPA3.SYS

LIBPATH=E:\Development\IBMCPP\DLL;
SET
PATH=E:\Development\IBMCPP\BIN;E:\Development\IBMCPP\HELP;E:\Development\IBMCPP
\SMARTS\SCRIPTS;
SET
DPATH=E:\Development\IBMCPP\HELP;E:\Development\IBMCPP;E:\Development\IBMCPP\LO
CALE;E:\Development\IBMCPP\MACROS;E:\Development\IBMCPP\BND;
SET HELP=E:\Development\IBMCPP\HELP;
SET BOOKSHELF=E:\Development\IBMCPP\HELP;
SET LIB=E:\Development\IBMCPP\LIB;
SET INCLUDE=E:\Development\IBMCPP\INCLUDE;E:\Development\IBMCPP\INCLUDE\SOM;
SET SMINCLUDE=E:\Development\IBMCPP\INCLUDE;E:\Development\IBMCPP\INCLUDE\SOM;

SET VACPP_SHARED=FALSE
SET CPPHELP_INI=C:\OS2\SYSTEM
SET CPPLOCAL=E:\Development\IBMCPP
SET CPPMAIN=E:\Development\IBMCPP
SET CPPWORK=E:\Development\IBMCPP
SET
LOCPATH=E:\Development\IBMCXXO\locale;E:\Development\IBMCPP40\Runtime\locale;E:
\Development\IBMCPP\LOCALE
SET IWFHELP=IWFHDI.INF
SET IWFOPT=E:\Development\IBMCPP
SET IWF.DEFAULT_PRJ=CPPDFTPRJ
SET IWF.SOLUTION_LANG_SUPPORT=CPPIBS30;ENG
SET THREADS=512
SET VBPATH=.;E:\Development\IBMCPP\DDE4VB
SET TMPDIR=E:\Development\IBMCPP\TMP
SET LXEVFREF=EVFELREF.INF+LPXCREF.INF
SET LXEVFHDI=EVFELHDI.INF+LPEXHDI.INF
SET LPATH=E:\Development\IBMCPP\MACROS
SET CODELPATH=E:\Development\IBMCPP\CODE\MACROS;E:\Development\IBMCPP\MACROS
SET
CLREF=CPPCLRF.INF+CPPDAT.INF+CPPAPP.INF+CPPWIN.INF+CPPCTL.INF+CPPADV.INF+CPP2DG
INF+CPPDDE.INF+CPPDM.INF+CPPMM.INF+CPPCLRB.INF
-------8<--------8<--------8<--------8<--------8<--------8<-------


For the WPS objects and stuff, try this REXX script:
http://www.altsan.org/programming/rexx/desktop_vac3.cmd

Again, replace the path at the top of the file with whatever's correct
for your system.

It may not do everything perfectly (I don't recall if I had to do some
extra stuff by hand afterwards) but it's a pretty good start.


--
Alex Taylor
Fukushima, Japan
http://www.altsan.org

Please take off hat when replying.

[Paul Ratcliffe]

On 26 Sep 2012 22:18:01 -0500, Alex Taylor <mai...@reply.to.address> wrote:

> SET THREADS=512

Interesting. What does that achieve? Not what you think...

[John Small]

On Thu, 27 Sep 2012 03:18:01 UTC, "Alex Taylor"
<mai...@reply.to.address> wrote:

> On Tue, 25 Sep 2012 15:45:12 UTC, "John Small" <jsm...@os2world.net> wrote:
>
> > I am looking into setting up VACPP v3.08. I had this installed on a
> > previous computer and I still have the VACPP files from the
> > installation on that system.
> >
> > Hoping to avoid re-installing from scratch (including the various
> > patches), I'm wondering if it is possible to just copy the files and
> > set the relevant environment variables to get a functional VACPP.
>
> Sure. I did that; I got the desktop stuff working too, actually,
> with a little prior planning.
>
> Update CONFIG.SYS with the following, replacing E:\Development\IBMCPP
> with the correct path. (Watch out for extraneous line breaks in this
> post.)

1) This is for VACPP 3.08, correct?
2) I was thinking of putting as little as possible in CONFIG.SYS and
putting all the others into a CMD file I would run when I am about to
use VACPP. The DEVICE statement, if used, clearly would need to be in
CONFIG.SYS. And I suspect that the THREADS statement, if used, would
also need to be in CONFIG.SYS. If I change the LIBPATH to SET
BEGINLIBPATH, how many of the other statements could be put in a CMD
file instead of CONFIG.SYS?

> DEVICE=E:\Development\IBMCPP\SYS\CPPOPA3.SYS

1) What is this for? I did not have such a statement in my previous
CONFIG.SYS.
2) If I use this statement. does it mean I must include all the other
statements in CONFIG.SYS, too (so that the driver can find things)?

> SET CPPHELP_INI=C:\OS2\SYSTEM

Is there a reason this has to be a system directory? Could it point
somewhere else?

> SET THREADS=512

1) I assume that a higher value, which is already in my current
config.sys, would be acceptable.
2) I have several config.sys files from other installations and most
use
THREADS=number
instead of
SET THREADS=number
Is the "SET" optional? (Does this mean than THREADS is a pseudo env.
variable?)
3) Does this statement have to be in CONFIG.SYS to mean anything?

> For the WPS objects and stuff, try this REXX script:
> http://www.altsan.org/programming/rexx/desktop_vac3.cmd
>
> Again, replace the path at the top of the file with whatever's correct
> for your system.
>
> It may not do everything perfectly (I don't recall if I had to do some
> extra stuff by hand afterwards) but it's a pretty good start.

Thank you for all this!

[Doug Bissett]

On Thu, 27 Sep 2012 12:42:05 UTC, "John Small" <jsm...@os2world.net>
wrote:

> > SET THREADS=512
>
> 1) I assume that a higher value, which is already in my current
> config.sys, would be acceptable.
> 2) I have several config.sys files from other installations and most
> use
> THREADS=number
> instead of
> SET THREADS=number
> Is the "SET" optional? (Does this mean than THREADS is a pseudo env.
> variable?)
> 3) Does this statement have to be in CONFIG.SYS to mean anything?
>

Years ago, I remember looking at this. The details are a little fuzzy,
but:

SET THREADS=512 is something that VAC308 uses to contriol how many
threads it will try to use. This needs to be "seen" by VAC308, when it
runs, and it can be in a launch script, instead of in CONFIG.SYS.

THREADS=1024 is something that OS/2 uses to control the number of
threads that are available for all programs to use. This must be in
CONFIG.SYS.

I would assume, that VAC308 is trying to eliminate the possibility
that it might use up all of the threads, leaving everything else in
limbo.

HTH
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[Paul Ratcliffe]

On Thu, 27 Sep 2012 12:42:05 +0000 (UTC), John Small <jsm...@os2world.net>
wrote:

> 2) I was thinking of putting as little as possible in CONFIG.SYS and
> putting all the others into a CMD file I would run when I am about to
> use VACPP. The DEVICE statement, if used, clearly would need to be in
> CONFIG.SYS. And I suspect that the THREADS statement, if used, would
> also need to be in CONFIG.SYS. If I change the LIBPATH to SET
> BEGINLIBPATH, how many of the other statements could be put in a CMD
> file instead of CONFIG.SYS?

Most of it can go in a batch file. I reckon "SET THREADS" should be just
"THREADS". It's barely needed anyway as nothing relating to the compiler
is going to use anything like that number anyway.
Just ignore what Bissett says. He know nothing, not being (by his own
admission) a systems programmer.

>> DEVICE=E:\Development\IBMCPP\SYS\CPPOPA3.SYS
>
> 1) What is this for? I did not have such a statement in my previous
> CONFIG.SYS.

Something related to the Performance Analyzer IIRC. You can do without
it, but it has no noticable impact if you just leave it in.

> 2) If I use this statement. does it mean I must include all the other
> statements in CONFIG.SYS, too (so that the driver can find things)?
>
>> SET CPPHELP_INI=C:\OS2\SYSTEM

I suspect that is to do with the WPS stuff. I never installed it.
I would theink the command line compiler parts wouldn't need it as they
have no use for any such stuff.

> Is there a reason this has to be a system directory? Could it point
> somewhere else?

Presumably, otherwise why make it configurable?

>> SET THREADS=512
>
> 1) I assume that a higher value, which is already in my current
> config.sys, would be acceptable.

Obviously.

> 2) I have several config.sys files from other installations and most
> use
> THREADS=number
> instead of
> SET THREADS=number
> Is the "SET" optional? (Does this mean than THREADS is a pseudo env.
> variable?)

No, it has to be just THREADS.

> 3) Does this statement have to be in CONFIG.SYS to mean anything?

Yes.

[Paul Ratcliffe]

On Thu, 27 Sep 2012 15:14:59 +0000 (UTC), Doug Bissett
<dougb007!SP...@telus.net> wrote:

> Years ago, I remember looking at this. The details are a little fuzzy,
> but:
>
> SET THREADS=512 is something that VAC308 uses to contriol how many
> threads it will try to use. This needs to be "seen" by VAC308, when it
> runs, and it can be in a launch script, instead of in CONFIG.SYS.

I smell some more Bissett Bullshit.

I've never had any such statement in my CONFIG.SYS and VAC has always
been fine. Why do you expect a compiler to use hundreds of threads
anyway?
You don't have to answer that one. I know you don't know the answer.

[A.D. Fundum]

> I was thinking of putting as little as possible in CONFIG.SYS

Verify the file VACPP.PKG in your backupped files. For example, it
seems SET THREADS=512 is REM'med out in CSETENV.CMD if you had it in
your CONFIG.SYS. You may want to remove the REM then.


--

[Doug Bissett]

It is somewhere in the VAC308 docs, which I no longer have installed
(and the line is inserted into CONFIG.SYS by the VAC308 installer).
Chances are, that you never compiled anything that requires enough
threads to kill the system (or, perhaps you did, and didn't recognize
what the problem was).

Again, Paul makes a completely useless post, without first making sure
that he knows what he is talking about.

[A.D. Fundum]

NHS: fail. Knowledge of installers: fail.

> He know nothing

> Something related to the Performance Analyzer IIRC.

> I suspect
> I would theink
> such stuff
> Presumably

> No, it has to be just THREADS.

I would think I suspect it's presumably something related to VAC3,
IIRC. Such stuff isn't just THREADS.


--

[Peter Flass]

It's a *compiler*, how the heck many threads *could* it use???


--
Pete

[Paul Ratcliffe]

What *ARE* you wittering on about?

[Paul Ratcliffe]

On Thu, 27 Sep 2012 18:22:29 +0000 (UTC), Doug Bissett

<dougb007!SP...@telus.net> wrote:

>> > Years ago, I remember looking at this. The details are a little fuzzy,
>> > but:
>> >
>> > SET THREADS=512 is something that VAC308 uses to contriol how many
>> > threads it will try to use. This needs to be "seen" by VAC308, when it
>> > runs, and it can be in a launch script, instead of in CONFIG.SYS.
>>
>> I smell some more Bissett Bullshit.
>>
>> I've never had any such statement in my CONFIG.SYS and VAC has always
>> been fine. Why do you expect a compiler to use hundreds of threads
>> anyway?
>> You don't have to answer that one. I know you don't know the answer.
>
> It is somewhere in the VAC308 docs, which I no longer have installed

Who believes the docs.? You can observe with your own eyes, if you
bothered to look, which of course you didn't.

> (and the line is inserted into CONFIG.SYS by the VAC308 installer).

Not by mine.

> Chances are, that you never compiled anything that requires enough
> threads to kill the system (or, perhaps you did, and didn't recognize
> what the problem was).

Chances are? WTF are you on about? XWP complicated enough for you?
Even that only executes at most two or three processes at once.
I repeat, what in a compiler do you expect to use hundreds of threads?
Can you PLEASE answer that question?

> Again, Paul makes a completely useless post, without first making sure
> that he knows what he is talking about.

Er, Douggy boy, is it you who makes useless posts, not me. You have
clearly proved on many occasions YOU don't know what YOU are talking
about.

[Alex Taylor]

On Thu, 27 Sep 2012 09:11:38 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> > SET THREADS=512
>
> Interesting. What does that achieve? Not what you think...

I have no idea but it was apparently added by the VACPP 3.x installer
so I retained it.

I know it's different from "THREADS=xxx" (which is a system directive),
but I assume it has some meaning to something in VAC.

[A.D. Fundum]

0. Wtf cares?
1. His filter is broken, again.
2. NLOL. He's wrong, again (*, **)... :-(
3. He's trying to change the subjects, again.
4. It's a mystery, but all of my machines with an installed VAC 3.0x
have SET THREADS=512 in x:\CONFIG.SYS. Strange.
5. He fails to admit that lines 5298 upto and including 5304 of the
file VACPP.PKG (a.o. root directory of the CD) learn that SET
THREADS=512 are added to a CONFIG.*-file by VAC's installer
6. He fails to admit that lines 5298 upto and including 5304 of the
file VACPP.PKG (a.o. root directory of the CD) learn that SET
THREADS=512 isn't THREAD=512, his own original, irrelevant story.
7. NURSE! He's out of bed again.
8. Get well soon.

*: regarding the 3.0 installer; not the 3.08 installer, albeit he
failed to mention that.
**: in rare cases it's possible to not let the installer update the
CONFIG.SYS and to not update it manually, albeit he failed to mention
such a rather unusual install procedure.

IOW: in a typical situation the installer processes VACPP.PKG, which
causes a line reading SET THREADS=512 to be added to CONFIG.SYS. The
line is also added to CSETENV.CMD. With a REM in front of it, because
it should already be defined in CONFIG.SYS. I'll try to care less, but
maybe "systems programmers" (I am impressed!) received another install
CD and a package which never could need this SETting.


--

[Alex Taylor]

On Thu, 27 Sep 2012 12:42:05 UTC, "John Small" <jsm...@os2world.net> wrote:

> > Update CONFIG.SYS with the following, replacing E:\Development\IBMCPP
> > with the correct path. (Watch out for extraneous line breaks in this
> > post.)
>
> 1) This is for VACPP 3.08, correct?

Yes.

> 2) I was thinking of putting as little as possible in CONFIG.SYS and
> putting all the others into a CMD file I would run when I am about to
> use VACPP. The DEVICE statement, if used, clearly would need to be in
> CONFIG.SYS. And I suspect that the THREADS statement, if used, would
> also need to be in CONFIG.SYS. If I change the LIBPATH to SET
> BEGINLIBPATH, how many of the other statements could be put in a CMD
> file instead of CONFIG.SYS?

The SET THREADS statement (whatever it does) is an environment variable
so it might be fine to put it in a CMD file. Don't confuse it with the
THREADS=xxx (no SET) kernel directive, which does belong in CONFIG.SYS,
but I see no reason for you to mess with that.

> > DEVICE=E:\Development\IBMCPP\SYS\CPPOPA3.SYS
>
> 1) What is this for? I did not have such a statement in my previous
> CONFIG.SYS.

I don't recall but I gather from my own experience that it's not
necessary to compile stuff, at least.

> 2) If I use this statement. does it mean I must include all the other
> statements in CONFIG.SYS, too (so that the driver can find things)?

Can't answer that, I'm afraid.

I don't know all the ins and outs of what this all does, just that
these are what the VACPP installer put in my CONFIG.SYS - so I kept
them.

> > SET CPPHELP_INI=C:\OS2\SYSTEM
>
> Is there a reason this has to be a system directory? Could it point
> somewhere else?

I'm sure you can put it wherever you like, but most things put their
INIs either in \OS2 or in the same location as OS2.INI (if different).
IMO it makes sense to keep them in one place.

> > SET THREADS=512
>
> 1) I assume that a higher value, which is already in my current
> config.sys, would be acceptable.
> 2) I have several config.sys files from other installations and most use
> THREADS=number
> instead of
> SET THREADS=number
> Is the "SET" optional? (Does this mean than THREADS is a pseudo env.
> variable?)

Again, they are evidently not the same thing; I assume "SET THREADS"
means something to programs that look for it, but may not have any
significance to the OS itself.

> 3) Does this statement have to be in CONFIG.SYS to mean anything?

See above.

[Doug Bissett]

On Thu, 27 Sep 2012 19:19:19 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> On Thu, 27 Sep 2012 18:22:29 +0000 (UTC), Doug Bissett
> <dougb007!SP...@telus.net> wrote:
>
> >> > Years ago, I remember looking at this. The details are a little fuzzy,
> >> > but:
> >> >
> >> > SET THREADS=512 is something that VAC308 uses to contriol how many
> >> > threads it will try to use. This needs to be "seen" by VAC308, when it
> >> > runs, and it can be in a launch script, instead of in CONFIG.SYS.
> >>
> >> I smell some more Bissett Bullshit.
> >>
> >> I've never had any such statement in my CONFIG.SYS and VAC has always
> >> been fine. Why do you expect a compiler to use hundreds of threads
> >> anyway?
> >> You don't have to answer that one. I know you don't know the answer.
> >
> > It is somewhere in the VAC308 docs, which I no longer have installed
>
> Who believes the docs.? You can observe with your own eyes, if you
> bothered to look, which of course you didn't.

????? Now there is an intelligent statement...

> > (and the line is inserted into CONFIG.SYS by the VAC308 installer).
>
> Not by mine.

So, you didn't install the package using the defaults. Why am I not
surprised?

> > Chances are, that you never compiled anything that requires enough
> > threads to kill the system (or, perhaps you did, and didn't recognize
> > what the problem was).
>
> Chances are? WTF are you on about? XWP complicated enough for you?
> Even that only executes at most two or three processes at once.
> I repeat, what in a compiler do you expect to use hundreds of threads?
> Can you PLEASE answer that question?

How would I know? Perhaps the OS/2 development team had a problem when
they were building Warp4, and did something about it.

> > Again, Paul makes a completely useless post, without first making sure
> > that he knows what he is talking about.
>
> Er, Douggy boy, is it you who makes useless posts, not me. You have
> clearly proved on many occasions YOU don't know what YOU are talking
> about.

You requested to be notified when you make useless posts. Consider
yourself notified.

I did say that the details were somewhat fuzzy, but the basic idea is
that "SET THREADS=512" means something to VACPP (probably an upper
limit to the number of threads that it will try to use - why? I don't
know, nor do I care). "THREADS=1024" is an instruction to the kernel
to govern the number of threads that are available. YOU challenged
that, as being incorrect, but have not presented anything to clarify
the situation. All you did was argue that SET THREADS=512 was not
installed in your CONFIG.SYS, so it isn't necessary. It probably isn't
in almost all cases, but it obviously means something to VACPP, and
somebody needed it for something, or it wouldn't exist at all. My main
purpose in setting forth that argument was to point out that "SET
THREADS=512" is something quite different to "THREADS=1024". I think I
did that the first time, and you disagreed. YOU are WRONG. Not me.

[Paul Ratcliffe]

On Fri, 28 Sep 2012 03:20:35 +0200, A.D. Fundum <what...@neverm.ind> wrote:

> 0. Wtf cares?

Not me. You're just a fucking wittering incompetent idiot.

> IOW: in a typical situation the installer processes VACPP.PKG, which
> causes a line reading SET THREADS=512 to be added to CONFIG.SYS.

Yes but what does it achieve? I bet you cannot tell the difference with
it in or out.
Who's to say, in the general confusion about whether a "SET " is needed
on the front of it or not, that the geniuses at IBM Toronto where the
C compiler was developed didn't get all confused too and mis-wrote
the package file.
Stranger things have happened. It just makes no sense to add such a line.
You think they're God and can't get it wrong. I'm telling you they're not
and they can (and did).

Now run along and don't bother me again.

[Doug Bissett]

On Fri, 28 Sep 2012 08:47:20 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> On Fri, 28 Sep 2012 03:20:35 +0200, A.D. Fundum <what...@neverm.ind> wrote:
>
> > 0. Wtf cares?
>
> Not me. You're just a fucking wittering incompetent idiot.

Now that is an intelligent statement. Look in the mirror when you say
things like that.

> > IOW: in a typical situation the installer processes VACPP.PKG, which
> > causes a line reading SET THREADS=512 to be added to CONFIG.SYS.
>
> Yes but what does it achieve? I bet you cannot tell the difference with
> it in or out.
> Who's to say, in the general confusion about whether a "SET " is needed
> on the front of it or not, that the geniuses at IBM Toronto where the
> C compiler was developed didn't get all confused too and mis-wrote
> the package file.

Well, if the VACPP package actually does something with the entry, it
should be included, and yes, it does require the "SET", because that
is the way that it was implemented. This thread started with confusion
about "SET THREADS=" and "THREADS=" They are NOT the same, and each
has it's own use, whether you believe it, or not. Even if the
statement is not correct, it is prudent to include it, simply because
there is an outside chance that it will be needed. If it is not
needed, it obviously will do no harm.

> Stranger things have happened. It just makes no sense to add such a line.

Why not? You, obviously, have no idea what it is needed for. That
doesn't mean that it doesn't make sense, it just means that you don't
know what it is used for. There is nothing "strange" about it.
Somebody needed whatever it happens to do, so it exists, and it was
deemed important enough to make it a default setting in the installer.

> You think they're God and can't get it wrong. I'm telling you they're not
> and they can (and did).

No they didn't. It obviously does what it is supposed to do (or, it
does nothing). Just because you don't happen to have run into the
problem that it fixes, doesn't mean that others don't need it.

You, obviously, don't know what they did, or why. That doesn't make it
wrong, it just makes you claim to know something, that you obviously
don't know. There is no doubt that mistakes were made, but every
program ever written has bugs in it. Even your programs have bugs.

By the way, aren't you the one who is calling down Lars because he
criticised somebody else's work? Pot, Kettle, Black.

> Now run along and don't bother me again.

Hmmm. Seems to me that YOU are the one who is doing the bothering.
Now, run along, and quit bothering those who are trying to be helpful.

[Paul Ratcliffe]

On Fri, 28 Sep 2012 17:52:29 +0000 (UTC), Doug Bissett
<dougb007!SP...@telus.net> wrote:

>> Yes but what does it achieve? I bet you cannot tell the difference with
>> it in or out.
>> Who's to say, in the general confusion about whether a "SET " is needed
>> on the front of it or not, that the geniuses at IBM Toronto where the
>> C compiler was developed didn't get all confused too and mis-wrote
>> the package file.
>
> Well, if the VACPP package actually does something with the entry, it
> should be included, and yes, it does require the "SET", because that
> is the way that it was implemented. This thread started with confusion
> about "SET THREADS=" and "THREADS=" They are NOT the same, and each
> has it's own use, whether you believe it, or not.

I don't believe "SET THREADS=" has any use. That's the whole point of
the argument, which YET AGAIN you have missed the point about.

> Even if the
> statement is not correct, it is prudent to include it, simply because
> there is an outside chance that it will be needed. If it is not
> needed, it obviously will do no harm.

If it doesn't do any good, what's the point in keeping it?
If just gives fools like you excuses to trot out arguments like this
one for ever and a day.
You still haven't given any indication of what all these hundreds
of potential threads are doing.
Is it because (shock horror) you don't know?

>> Stranger things have happened. It just makes no sense to add such a line.
>
> Why not? You, obviously, have no idea what it is needed for. That
> doesn't mean that it doesn't make sense, it just means that you don't
> know what it is used for. There is nothing "strange" about it.
> Somebody needed whatever it happens to do, so it exists, and it was
> deemed important enough to make it a default setting in the installer.

You just can't ever accept anything might be wrong can you?

>> You think they're God and can't get it wrong. I'm telling you they're not
>> and they can (and did).
>
> No they didn't.

How the hell do you know?

> It obviously does what it is supposed to do (or, it
> does nothing). Just because you don't happen to have run into the
> problem that it fixes, doesn't mean that others don't need it.

You don't need much intelligence to work out that it does nothing.
You haven't worked it out. That tells us your intelligence level.

> You, obviously, don't know what they did, or why. That doesn't make it
> wrong, it just makes you claim to know something, that you obviously
> don't know.

Well you're the bleedin' expert on that, aren't you?
Do you want me to include <sarcasm> tags with that, or can you work it
out for yourself?

> By the way, aren't you the one who is calling down Lars because he
> criticised somebody else's work? Pot, Kettle, Black.

I didn't criticise Lars. All I did was point out one small factual
inaccuracy, and you come wading in with both feet.

> Now, run along, and quit bothering those who are trying to be helpful.

The whole point is that you are not helpful by spreading misinformation.

[Paul Ratcliffe]

On Fri, 28 Sep 2012 05:21:54 +0000 (UTC), Doug Bissett
<dougb007!SP...@telus.net> wrote:

>> > It is somewhere in the VAC308 docs, which I no longer have installed
>>
>> Who believes the docs.? You can observe with your own eyes, if you
>> bothered to look, which of course you didn't.
>
> ????? Now there is an intelligent statement...

I know. Obviously over your head.

>> > (and the line is inserted into CONFIG.SYS by the VAC308 installer).
>>
>> Not by mine.
>
> So, you didn't install the package using the defaults.

I have no idea now. I was countless years ago.

> Why am I not surprised?

Defaults are there to be changed, if they make no sense.
You seem to be implying this is a BAD thing. It is a GOOD thing.
You would stick with a bad setting, come hell or high water, just
because someone else told you to.
"Doug, go jump in the river would you?" "Sure."

>> > Chances are, that you never compiled anything that requires enough
>> > threads to kill the system (or, perhaps you did, and didn't recognize
>> > what the problem was).
>>
>> Chances are? WTF are you on about? XWP complicated enough for you?
>> Even that only executes at most two or three processes at once.
>> I repeat, what in a compiler do you expect to use hundreds of threads?
>> Can you PLEASE answer that question?
>
> How would I know?

So WHY are you arguing from a position of NO knowledge then?
You accuse me of same elsewhere but do it yourself.
You're just an ignorant hypocrite.

> Perhaps the OS/2 development team had a problem when
> they were building Warp4, and did something about it.

Perhaps they just fucked up a setting, like many other people have?

>> > Again, Paul makes a completely useless post, without first making sure
>> > that he knows what he is talking about.
>>
>> Er, Douggy boy, is it you who makes useless posts, not me. You have
>> clearly proved on many occasions YOU don't know what YOU are talking
>> about.
>
> You requested to be notified when you make useless posts. Consider
> yourself notified.

It's not a useless post. The balance of probabilities is way in my
favour, and way against yours.

> I did say that the details were somewhat fuzzy, but the basic idea is
> that "SET THREADS=512" means something to VACPP (probably an upper
> limit to the number of threads that it will try to use - why? I don't
> know, nor do I care).

You seem to care enough to have pointless arguments about it.

> "THREADS=1024" is an instruction to the kernel
> to govern the number of threads that are available.

That's the first thing you've got right this week.

> YOU challenged that, as being incorrect,

NO I DID NOT. WHERE EXACTLY DID I SAY ANY SUCH THING?

> but have not presented anything to clarify the situation.

Obviously, because I never said it. You have misinterpreted something.

> All you did was argue that SET THREADS=512 was not
> installed in your CONFIG.SYS, so it isn't necessary.

I made a statement (not an argument) that it wasn't installed and that
I had never seen any ill effects from it not being there.
Then you come back with some other crap which we won't go over again.

> It probably isn't
> in almost all cases, but it obviously means something to VACPP,

Nobody can think of what it might be used for. Compilers just don't
have any need for such a thing. Just believe it for once.

> My main
> purpose in setting forth that argument was to point out that "SET
> THREADS=512" is something quite different to "THREADS=1024". I think I
> did that the first time, and you disagreed. YOU are WRONG. Not me.

I think you have your wires crossed.

[Doug Bissett]

On Mon, 1 Oct 2012 00:39:16 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> On Fri, 28 Sep 2012 05:21:54 +0000 (UTC), Doug Bissett
> <dougb007!SP...@telus.net> wrote:
>
> >> > It is somewhere in the VAC308 docs, which I no longer have installed
> >>
> >> Who believes the docs.? You can observe with your own eyes, if you
> >> bothered to look, which of course you didn't.
> >
> > ????? Now there is an intelligent statement...
>
> I know. Obviously over your head.

Obviously...

> >> > (and the line is inserted into CONFIG.SYS by the VAC308 installer).
> >>
> >> Not by mine.
> >
> > So, you didn't install the package using the defaults.
>
> I have no idea now. I was countless years ago.
>
> > Why am I not surprised?
>
> Defaults are there to be changed, if they make no sense.
> You seem to be implying this is a BAD thing. It is a GOOD thing.
> You would stick with a bad setting, come hell or high water, just
> because someone else told you to.
> "Doug, go jump in the river would you?" "Sure."

If I was on a burning boat, sure I would.

You obviously know exactly what "SET THREADS=" does, and have decide
that it is not applicable to your requirements, so tell us what it
really does, since I obviously have no idea. Or, perhaps, you just got
lucky, and never needed it.

> >> > Chances are, that you never compiled anything that requires enough
> >> > threads to kill the system (or, perhaps you did, and didn't recognize
> >> > what the problem was).
> >>
> >> Chances are? WTF are you on about? XWP complicated enough for you?
> >> Even that only executes at most two or three processes at once.
> >> I repeat, what in a compiler do you expect to use hundreds of threads?
> >> Can you PLEASE answer that question?
> >
> > How would I know?
>
> So WHY are you arguing from a position of NO knowledge then?

It seems to me that you are too.

> You accuse me of same elsewhere but do it yourself.
> You're just an ignorant hypocrite.

Look in the mirror when you say that.

> > Perhaps the OS/2 development team had a problem when
> > they were building Warp4, and did something about it.
>
> Perhaps they just fucked up a setting, like many other people have?

Perhaps you just never bothered to find out what the setting does?

> >> > Again, Paul makes a completely useless post, without first making sure
> >> > that he knows what he is talking about.
> >>
> >> Er, Douggy boy, is it you who makes useless posts, not me. You have
> >> clearly proved on many occasions YOU don't know what YOU are talking
> >> about.
> >
> > You requested to be notified when you make useless posts. Consider
> > yourself notified.
>
> It's not a useless post. The balance of probabilities is way in my
> favour, and way against yours.

The balance of probabilities has nothing to do with it. Look up "SET
THREADS=" and tell us what it says. Apparently you still have the docs
installed. I don't, but I did look it up, years ago. As I said, the
details are a bit fuzzy.

> > I did say that the details were somewhat fuzzy, but the basic idea is
> > that "SET THREADS=512" means something to VACPP (probably an upper
> > limit to the number of threads that it will try to use - why? I don't
> > know, nor do I care).
>
> You seem to care enough to have pointless arguments about it.

You are the one who is arguing that "SET THREADS=" is something that
the developers screwed up. Is it? Why? How do you know?

> > "THREADS=1024" is an instruction to the kernel
> > to govern the number of threads that are available.
>
> That's the first thing you've got right this week.
>
> > YOU challenged that, as being incorrect,
>
> NO I DID NOT. WHERE EXACTLY DID I SAY ANY SUCH THING?

You edited what I said. Go back and READ what I posted.

> > but have not presented anything to clarify the situation.
>
> Obviously, because I never said it. You have misinterpreted something.
>
> > All you did was argue that SET THREADS=512 was not
> > installed in your CONFIG.SYS, so it isn't necessary.
>
> I made a statement (not an argument) that it wasn't installed and that
> I had never seen any ill effects from it not being there.
> Then you come back with some other crap which we won't go over again.
>
> > It probably isn't
> > in almost all cases, but it obviously means something to VACPP,
>
> Nobody can think of what it might be used for. Compilers just don't
> have any need for such a thing. Just believe it for once.

Why would I believe it, when the developers of VACPP didn't believe
it?

> > My main
> > purpose in setting forth that argument was to point out that "SET
> > THREADS=512" is something quite different to "THREADS=1024". I think I
> > did that the first time, and you disagreed. YOU are WRONG. Not me.
>
> I think you have your wires crossed.

I think you don't listen very well. The parameter exists. It is good
for something (even if YOU don't believe that), and it is considered
important enough, by the developers, to include the statement in the
default install. Since you don't seem to actually know what it is used
for, I think you should not be telling others that it is not
necessary. You just don't know that.

[Doug Bissett]

On Mon, 1 Oct 2012 00:24:55 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> On Fri, 28 Sep 2012 17:52:29 +0000 (UTC), Doug Bissett
> <dougb007!SP...@telus.net> wrote:
>
> >> Yes but what does it achieve? I bet you cannot tell the difference with
> >> it in or out.
> >> Who's to say, in the general confusion about whether a "SET " is needed
> >> on the front of it or not, that the geniuses at IBM Toronto where the
> >> C compiler was developed didn't get all confused too and mis-wrote
> >> the package file.
> >
> > Well, if the VACPP package actually does something with the entry, it
> > should be included, and yes, it does require the "SET", because that
> > is the way that it was implemented. This thread started with confusion
> > about "SET THREADS=" and "THREADS=" They are NOT the same, and each
> > has it's own use, whether you believe it, or not.
>
> I don't believe "SET THREADS=" has any use. That's the whole point of
> the argument, which YET AGAIN you have missed the point about.

Of course it has a use. It wouldn't exist if it didn't have a use. You
just don't know what that use is (nor do I, for sure)

> > Even if the
> > statement is not correct, it is prudent to include it, simply because
> > there is an outside chance that it will be needed. If it is not
> > needed, it obviously will do no harm.
>
> If it doesn't do any good, what's the point in keeping it?

Do you know what it does? How do you know that somebody else might not
need it?

> If just gives fools like you excuses to trot out arguments like this
> one for ever and a day.
> You still haven't given any indication of what all these hundreds
> of potential threads are doing.
> Is it because (shock horror) you don't know?

I know that VACPP is multithreaded. True, I don't know what the
threads are doing. Unlike you, I assume that the VACPP developers do
have some idea about what they are doing, so I defer to their
knowledge, and, since I don't know why they added that feature, I have
to assume that there is a good reason for it. Therefore, the statement
should be included, either in the CONFIG.SYS, or in the setup script
that starts VACPP.

> >> Stranger things have happened. It just makes no sense to add such a line.
> >
> > Why not? You, obviously, have no idea what it is needed for. That
> > doesn't mean that it doesn't make sense, it just means that you don't
> > know what it is used for. There is nothing "strange" about it.
> > Somebody needed whatever it happens to do, so it exists, and it was
> > deemed important enough to make it a default setting in the installer.
>
> You just can't ever accept anything might be wrong can you?

I am not wrong. You simply assume that you know more than the VACPP
developers. I assume that they know why they added that feature, and
that it has a use. Whether it is actually needed in any individual
situation, could be debated forever, until somebody does need it (and
probably spent days trying to figure it out).

> >> You think they're God and can't get it wrong. I'm telling you they're not
> >> and they can (and did).
> >
> > No they didn't.
>
> How the hell do you know?

How do you know that they "got it wrong"? You don't even know what it
is used for.

> > It obviously does what it is supposed to do (or, it
> > does nothing). Just because you don't happen to have run into the
> > problem that it fixes, doesn't mean that others don't need it.
>
> You don't need much intelligence to work out that it does nothing.
> You haven't worked it out. That tells us your intelligence level.

How do you know that it does nothing? Somebody needed it, for some
reason, or it wouldn't exist.

> > You, obviously, don't know what they did, or why. That doesn't make it
> > wrong, it just makes you claim to know something, that you obviously
> > don't know.
>
> Well you're the bleedin' expert on that, aren't you?

Expert? No. I just have to accept that the experts (the developers)
did know what they were doing. I don't have to accept that you are a
better expert, especially since you have demonstrated that you don't
even know what the feature actually does. I speculated (from having
done research on it, years ago), and you flat out said I was wrong. As
I said, perhaps I am wrong. You seem to have the docs still installed.
What do they have to say about it?

> Do you want me to include <sarcasm> tags with that, or can you work it
> out for yourself?
>
> > By the way, aren't you the one who is calling down Lars because he
> > criticised somebody else's work? Pot, Kettle, Black.
>
> I didn't criticise Lars. All I did was point out one small factual
> inaccuracy, and you come wading in with both feet.

All I did was comment about the widget. YOU are the one who jumped in

with both feet.

> > Now, run along, and quit bothering those who are trying to be helpful.
>
> The whole point is that you are not helpful by spreading misinformation.

And you are not helpful by not appending the correct information (if I
am, in fact, not correct, which you have not proven). All you have
done is supply anecdotal evidence that YOU have never needed whatever
"SET THREADS=" does. That doesn't mean that others might not need it.
You have also speculated that the VACPP developers screwed up by
creating such a thing. Did they? How do you know? I am no expert on
what VACPP does, or how, so I must assume thet those who do know (the
developers) have some idea of why "SET THREADS=" is included in the
default install. I also need to assume that they know why they put it
in there. Just because YOU don't need it, doesn't mean that others
don't need it.

[Paul Ratcliffe]

On Mon, 1 Oct 2012 17:07:19 +0000 (UTC), Doug Bissett
<dougb007!SP...@telus.net> wrote:

> You obviously know exactly what "SET THREADS=" does, and have decide
> that it is not applicable to your requirements, so tell us what it
> really does, since I obviously have no idea. Or, perhaps, you just got
> lucky, and never needed it.

I don't know what it does. Duh, that's the whole point. NOBODY seems to
know, yet you maintain it's required for something, but you don't know what.

>> > Perhaps the OS/2 development team had a problem when
>> > they were building Warp4, and did something about it.
>>
>> Perhaps they just fucked up a setting, like many other people have?
>
> Perhaps you just never bothered to find out what the setting does?

How exactly? The fact remains that compiler applications do not use
hundreds of threads.

> The balance of probabilities has nothing to do with it. Look up "SET
> THREADS=" and tell us what it says. Apparently you still have the docs
> installed. I don't, but I did look it up, years ago. As I said, the
> details are a bit fuzzy.

Anything to shut you up...
The only reference I could find was in the "VAC++ User's Guide/Ref."
where it talks about CONFIG.SYS and CSETENV.CMD

"
The VisualAge C++ compiler checks the OS/2 environment variables
for path information and for the default values of compiler options. If
the VisualAge C++ installation program updated your CONFIG.SYS file,
many of the environment variables already have values for the
compiler to use. If the program did not update CONFIG.SYS, you can
set these values by running the CSETENV.CMD file in your OS/2
session before using the compiler.
"

In VACPP.PKG it says

"
ADDCONFIG
VAR = 'SET THREADS',
ADDSTR = '512',
ADDWHEN = 'INSTALL || UPDATE || RESTORE',
UNIQUE = 'YES',
DELETEWHEN = 'DELETE',
DELETELINE = 'YES'
"

In CSETENV.CMD it says
"
@rem SET THREADS=512
"

The other lines that are remmed out are "DEVICE" and "LIBAPTH" statements.
This strongly suggests to me that the things that are remmed out are
those that you CANNOT set in the environment. Obviously you are able to
do "SET THREADS" in the environment, so why rem it out?
It is fairly obvious to me that "SET THREADS" was meant to be "THREADS"
all along, AS I ORIGINALLY SUGGESTED, and that the "SET " is indeed an
error.

> You are the one who is arguing that "SET THREADS=" is something that
> the developers screwed up. Is it? Why? How do you know?

As I've just explained.

>> > "THREADS=1024" is an instruction to the kernel
>> > to govern the number of threads that are available.
>>
>> That's the first thing you've got right this week.
>>
>> > YOU challenged that, as being incorrect,
>>
>> NO I DID NOT. WHERE EXACTLY DID I SAY ANY SUCH THING?
>
> You edited what I said. Go back and READ what I posted.

Frankly, I can't be bothered. I've posted enough to know that I am
right and you are wrong.
If you still don't believe me I don't care. All I care about it that
other people don't believe your drivel.

>> Nobody can think of what it might be used for. Compilers just don't
>> have any need for such a thing. Just believe it for once.
>
> Why would I believe it, when the developers of VACPP didn't believe
> it?

They made a mistake. Get over it.

>
>> > My main
>> > purpose in setting forth that argument was to point out that "SET
>> > THREADS=512" is something quite different to "THREADS=1024". I think I
>> > did that the first time, and you disagreed. YOU are WRONG. Not me.
>>
>> I think you have your wires crossed.
>
> I think you don't listen very well. The parameter exists. It is good
> for something

You can't say what for or why. I have said why not.

> (even if YOU don't believe that), and it is considered
> important enough, by the developers, to include the statement in the
> default install. Since you don't seem to actually know what it is used
> for, I think you should not be telling others that it is not
> necessary. You just don't know that.

You don't know that it IS necessary. You just can't get over the fact
that maybe IBM got it wrong, can you?
Jeez, I've never come across anyone so blinkered and unwilling to accept
things as you.

[Paul Ratcliffe]

On Mon, 1 Oct 2012 17:07:20 +0000 (UTC), Doug Bissett <dougb007!SP...@telus.net>
wrote:

>> I don't believe "SET THREADS=" has any use. That's the whole point of
>> the argument, which YET AGAIN you have missed the point about.
>
> Of course it has a use. It wouldn't exist if it didn't have a use. You
> just don't know what that use is (nor do I, for sure)

So if I put
"SET BISSETT_IS_A_TOSSER=TRUE"
in my CONFIG.SYS file, would that automatically make it have a use and
mean I didn't have to read any more of your tedious crap?

Of course not, sadly.

> I know that VACPP is multithreaded. True, I don't know what the
> threads are doing. Unlike you, I assume that the VACPP developers do
> have some idea about what they are doing, so I defer to their
> knowledge, and, since I don't know why they added that feature, I have
> to assume that there is a good reason for it. Therefore, the statement
> should be included, either in the CONFIG.SYS, or in the setup script
> that starts VACPP.

You try it, with and without and see what differences you can spot.
Than tell me it is needed. Hell will freeze over before you come back
with an example.

> Expert? No. I just have to accept that the experts (the developers)
> did know what they were doing.

That is your fundamental mistaken assumption. Everything else falls
apart from there on in. Developers are not Gods. How do you know it
wasn't some kid on his first day given a job to edit the VACPP.PKG file
who added that SET statement without realising it was wrong?

[Doug Bissett]

On Mon, 15 Oct 2012 16:45:14 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> Jeez, I've never come across anyone so blinkered and unwilling to accept
> things as you.

You just never met anybody who could be bothered to call you on your
statements. Now HOW DO YOU KNOW?

[Doug Bissett]

On Mon, 15 Oct 2012 16:52:58 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> How do you know it
> wasn't some kid on his first day given a job to edit the VACPP.PKG file
> who added that SET statement without realising it was wrong?

How do you know that it was like that?

[Andy]

On Mon, 15 Oct 2012 16:45:14 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> On Mon, 1 Oct 2012 17:07:19 +0000 (UTC), Doug Bissett
> <dougb007!SP...@telus.net> wrote:
>
> > You obviously know exactly what "SET THREADS=" does, and have decide
> > that it is not applicable to your requirements, so tell us what it
> > really does, since I obviously have no idea. Or, perhaps, you just got
> > lucky, and never needed it.
>
> I don't know what it does. Duh, that's the whole point. NOBODY seems to
> know, yet you maintain it's required for something, but you don't know what.
>

The VAC installer put the set threads = 512 in the setup scripts it
created here but it added @rem in front of it so it. It has been so
long ago that I had installed it that I have no idea if that was due
to some selection I made or not but I am relatively certain I did not
add the @rem myself.

[Paul Ratcliffe]

On Tue, 16 Oct 2012 21:43:18 +0000 (UTC), Andy <abwi...@yahoo.com> wrote:

>> > You obviously know exactly what "SET THREADS=" does, and have decide
>> > that it is not applicable to your requirements, so tell us what it
>> > really does, since I obviously have no idea. Or, perhaps, you just got
>> > lucky, and never needed it.
>>
>> I don't know what it does. Duh, that's the whole point. NOBODY seems to
>> know, yet you maintain it's required for something, but you don't know what.
>>
> The VAC installer put the set threads = 512 in the setup scripts it
> created here but it added @rem in front of it so it. It has been so
> long ago that I had installed it that I have no idea if that was due
> to some selection I made or not but I am relatively certain I did not
> add the @rem myself.

Likewise. The balance of probabilities is with me, rather than with
Douggy-boy.
I know he dismissed that phrase, but in reality as no-one knows the
facts at this point, it is the only thing that really counts.