Did the E3033 problem get resolved?

[W. eWatson]

usr1 posted some time ago that he experienced a problem with creating a
library, and combining it with a main program. The relevant part from
the long thread here I think is this:
==================
You could put the subroutines in a library thus
wfl386 /c sub1.for
wfl386 /c sub2.for
wlib mylib.lib +sub1.obj +sub2.obj

Then compile and link mainp.for to the library
wfl386 mainp.for mylib.lib
==================
(BTW, what's the /c for?

I wrote a small fortran program that contained about 10 lines of code
and another for a subroutine. Using the IDE, I successfully executed the
program. There was no obvious way there to create a lib for the
subroutine, so I tried the method above. All went well until I executed
the wlf386 command. I got the E3033 error message and a complaint about
"Error: ... line 4:directive error near librarymylib.lib". That was
followed by "Error: linker returned a bad status"

I found a description for 3033, MSG 2033,3033 directive error near ’%s.
Whatever %s means?

Later others thought it might be a bug. Someone suggested using
wfc386/wlink as a workaround, and that ended the thread.

So what is the right answer? wfc386/link mainp.for mylib.lib

[Kevin G. Rhoads]

...
>wfl386 /c sub1.for
...

>(BTW, what's the /c for?

CL is C-compile and Link, FL is Fortran-compile and Link
WCL is Watcom C-compile and Link, WFL is Watcom Fortran-compile and Link
WCL386 is Watcom C-compile and Link (32 bit for 386 and above)
and, finally,
WFL386 is Watcom Fortran-compile and Link (32 bit for 386 and above)


If you just want to compile you either use the /c (compile only) option OR
use a different tool (such as WFC386 (Watcom Fortran-Compile (32 bit)))

[dpb]

On 11/4/2011 12:08 AM, W. eWatson wrote:
...

> You could put the subroutines in a library thus
> wfl386 /c sub1.for
> wfl386 /c sub2.for
> wlib mylib.lib +sub1.obj +sub2.obj
>
> Then compile and link mainp.for to the library
> wfl386 mainp.for mylib.lib
> ==================
> (BTW, what's the /c for?

Do you _never_ read the help files? Or, execute

wfl386 |more

...

> and another for a subroutine. Using the IDE, I successfully executed the
> program. There was no obvious way there to create a lib for the

> subroutine,...

I've told you how to do this several times before, as well, and it's
also in the tutorial you didn't like.

Create a new project for the library you want to make. The IDE will
prompt for the image type to build; select "Lib". Then you reference
that library in whatever project(s) need it just like the libraries are
referenced in the "kitchen" tutorial.

It's the same principle as used in Visual Studio w/ only a very slightly
different interface.


> ... so I tried the method above. All went well until I executed

> the wlf386 command. I got the E3033 error message and a complaint about
> "Error: ... line 4:directive error near librarymylib.lib". That was
> followed by "Error: linker returned a bad status"

...

> Later others thought it might be a bug. Someone suggested using
> wfc386/wlink as a workaround, and that ended the thread.
>
> So what is the right answer? wfc386/link mainp.for mylib.lib

...

It is a bug. Did a test here. Built a test app and library
testfor.for, testlib.lib

The directive file generated was

system nt
name testfor
file testfor.obj
librarytestlib.lib

Note there's a missing space on the library directive--it should be

library testlib.lib

The same under Watcom V11 works correctly so this somehow got introduced
into the current (or an earlier and is still here) OW build. :(

wfc386 and wlink will work.

For the above

wfc386 testfor.for
wfc385 testlib.lib
wlib testlib +testlib.obj
wlink system nt name testfor file testfor[.obj] library testfor[.lib]

Normally one makes a make file or uses a batch file rather than all
manually, of course.

I didn't do the IDE version...

--

[dpb]

On 11/4/2011 10:40 AM, Kevin G. Rhoads wrote:
> ....
>> wfl386 /c sub1.for
> ....
...

> WFL386 is Watcom Fortran-compile and Link (32 bit for 386 and above)
>

...

Kevin, note that the E3033 is a real problem in wfl386 in OW 1.9, though.

The .lnk file generated by wfl386 now is missing a space on the library
directive line between the directive and the file name. This causes the
link step to fail.

It is a bug introduced somewhere along the way in OW builds--I had
continued to use Watcom V11.6 until trying to see if could lead our
friend here out of the wilderness I did download V1.9 of OW. I have
just confirmed (see other longer post) that it does the same thing here.

Can't see how that got past any regression testing into a release build...

--

[dpb]

On 11/4/2011 12:08 AM, W. eWatson wrote:
...

> Then compile and link mainp.for to the library
> wfl386 mainp.for mylib.lib

...

> the wlf386 command. I got the E3033 error message and a complaint about

> "Error: ... line 4:directive error near librarymylib.lib"....

BTW, the clue as to what went wrong is pretty easy to spot--the
"directive error near librarymylib.lib" has the library directive and
your requested library run together as noted before.

You can see this if you use the -FD switch to save the created .lnk
directive file (that otherwise is automagically deleted) and then look
at it as I did in the other posting.

If there isn't anything about a patch at the OW site or somebody around
to make a corrected rebuild in the short term, if you'll provide a valid
addy I'll be glad to forward the wfl386 executable from the V11 build
that works. I don't know for certain it will work w/ the OW
distribution -- well, let's see...ren, copy, wfl386...voila!!

Putting that version of wfl386.exe in the OWATCOM\BINNT directory
allowed to use it to build an executable compiled from a main .for and
linking w/ a .lib file w/o the E3033 error. Since Watcom is defunct and
passed on to OW, I don't see any problem in allowing the executable to
be used to get around a problem caused by some update build in the OW
distribution.

--

[dpb]

On 11/4/2011 1:00 PM, dpb wrote:
...

> wfc386 and wlink will work.
>
> For the above
>
> wfc386 testfor.for
> wfc385 testlib.lib

Dang typos... :( Above should be

wfc386 testlib.for

of course, to compile the library source before putting the object file
into the library.

> wlib testlib +testlib.obj
> wlink system nt name testfor file testfor[.obj] library testfor[.lib]

--

[Kevin G. Rhoads]

>Kevin, note that the E3033 is a real problem in wfl386 in OW 1.9, though.

OK - I wasn't commenting on that as I had no experience to offer on that matter.

It is good that someone can confirm the real issue there.

[Hans-Bernhard Bröker]

On 04.11.2011 06:08, W. eWatson wrote:

> Later others thought it might be a bug. Someone suggested using
> wfc386/wlink as a workaround, and that ended the thread.

Looks like documentation isn't the only material you hate reading with
any attention to detail.

The bug was fixed in the development version, and the fix announced
right there in the thread days before it petered out.

[dpb]

On 11/4/2011 4:12 PM, Hans-Bernhard Bröker wrote:
...

> The bug was fixed in the development version, and the fix announced
> right there in the thread days before it petered out.

Interesting...I had totally forgotten that from a year+ ago even though
I read and responded in the thread... :(

But, the Winders build server is down so is there anywhere if the
corrected build wasn't inserted into the 1.9 distribution to actually
get a correct build at the moment? Don't know the OW site intimately,
but a moderately quick perusal didn't help...

--

[user1]

Grab it from the linux build server, as long as it is still up.

Actually, you can hexedit the appropriate string in the version 1.9
wfl386.exe file, if you are brave enough. Shorten library to lib
followed by 4 trailing spaces. Don't wish to talk OP through that
process, however.

[Kevin G. Rhoads]

>Actually, you can hexedit the appropriate string in the version 1.9
>wfl386.exe file, if you are brave enough.

Just make a backup copy first.

I did too much of that for the Ph.D. thesis, WP 4.2 for DOS, getting the font changes for Greek
into the auto-generated index and TOC. Fortunately, there were not too many Greek letters
in index entries. But I was too F***ing stubborn to change my wordings to avoid the issue.

Still, it was less fuss than TECO and a homebrew runoff for RT-11 on 8" floppies that I used
to write the Master's. (Run through the daisy-wheel, change to the Greek wheel and run it
through again. Joy.) I still have those floppies around, somewhere ...

[W. eWatson]

Oh, I only want to use Fortran, but was attracted to the sequence, since
I was trying to build a library to use with a main program.

[W. eWatson]

As a newcomer to this, it looks like if anyone wants to build a library
per the above commands they can't. Is there another way?

[W. eWatson]

On 11/4/2011 5:35 PM, Kevin G. Rhoads wrote:

[dpb]

On 11/4/2011 5:24 PM, user1 wrote:
...

> Grab it from the linux build server, as long as it is still up.

OH...DOH!

I was presuming those were running Linux builds under Linux; but I
realize that's not the way builds are built when you say so... :(

> Actually, you can hexedit the appropriate string in the version 1.9
> wfl386.exe file, if you are brave enough. Shorten library to lib
> followed by 4 trailing spaces. Don't wish to talk OP through that
> process, however.

Yeah, that would work but would seem far above OP's skill set, indeed.

I've got V11.6 so doesn't matter here, of course.

--

[dpb]

On 11/4/2011 9:58 PM, W. eWatson wrote:
...

> As a newcomer to this, it looks like if anyone wants to build a library
> per the above commands they can't. Is there another way?

Well, yes, I already posted an example using wfc386 and wlink to do the
same thing as wfl386 does. All wfl386 is is a front end for them; it's
nothing magic, just a convenience.

Or, as noted, go to

<http://owbuilder.malakovi.cz/snapshot/binnt/wfl386.exe>

and download the last make of wfl386 from the build server.

--

[Lynn McGuire]

We build several libraries in our software using 1.9
of Open Watcom and do not have this problem. However,
we use all command line tools. Works a lot better
with 700,000 lines of F77 code, 10,000 lines of C code
and 10,000 lines of C++ code. And over 6,000
subroutines and functions.

And we use the free crimson editor for source code
editing.

Lynn

[dpb]

On 11/5/2011 1:05 PM, Lynn McGuire wrote:
...

> We build several libraries in our software using 1.9
> of Open Watcom and do not have this problem. However,

> we use all command line tools....

It only exists in wfl386 (which is also command-line tool) just the
integrated compile/link front end that calls wfc386 and wlink in turn
(I'm not sure whether can also cram in wlib calls or not; don't really
think so, but never investigated fully), Lynn. You'll never see it
otherwise using the individual compile/librarian/link utilities.

The IDE builds a make file and submits it to wmake so it doesn't see the
problem, either.

And, of course, the OP has been pointed to the workaround or I offered
the V11 version and also provided the _direct_ link to the build server
from which he can download the last build in which the problem has been
fixed.

Is that sufficient? Would seem to most to be so, but apparently not to
this OP; he seems to prefer to complain and not bother with taking any
advice or direction nor bother to actually _read_ documentation it would
appear.

--

[dpb]

On 11/5/2011 1:05 PM, Lynn McGuire wrote:
...

> And we use the free crimson editor for source code
> editing.

I wasn't aware of Crimson...just went and found it. Interesting.

I've used Brief since first PC compiler and have so many customized
macros I have never yet been able to find a satisfactory replacement.
Fortunately, having retired from active consulting, I no longer code "in
anger" so it really isn't terribly important any longer.

For any who also miss Brief key layouts, I've recently discovered a
Windows pseudo-replacement at <www.briefeditor.com> It has key mappings
and the in-editor compilation/error, etc., the one lack in my case is it
doesn't implement Brief macros so all my customization is lost. In
private conversation w/ the author, he says it's on the horizon, but it
appears to me very unlikely it will ever happen both because it's a
sizable effort and the present command syntax isn't drop-in Brief
compatible as if it were intended from the beginning to do such. But,
it limited testing it seems stable and functional.

--

[Lynn McGuire]

Dont know. I'm an old mainframe hacker who moved to
PrimeOS to Vax to Unix to PC. Except for the PC, I
always used command lines tools instead of IDEs.
Nowadays I prefer IDEs but they must work and work
well. Watcom's IDE does not meet this requirement,
it is just too simplistic. So we just use the command
line tools provided by Watcom as they are robust and
simple.

We use Visual Studio exclusively for our user interface
(600,000 lines of C++ code) and some days I want to
throw it out the nearest window. BTW, when I first
tried to port our F77 code to Intel Fortran, we
overloaded it's linker internal tables and had to wait
a couple of months for a patch. Then I ran into their
zero init bug and gave up in disgust.

Lynn

[dpb]

On 11/5/2011 3:17 PM, Lynn McGuire wrote:
...

> Dont know. I'm an old mainframe hacker who moved to
> PrimeOS to Vax to Unix to PC. Except for the PC, I
> always used command lines tools instead of IDEs.
> Nowadays I prefer IDEs but they must work and work
> well. Watcom's IDE does not meet this requirement,
> it is just too simplistic. So we just use the command
> line tools provided by Watcom as they are robust and
> simple.
>
> We use Visual Studio exclusively for our user interface
> (600,000 lines of C++ code) and some days I want to
> throw it out the nearest window. BTW, when I first
> tried to port our F77 code to Intel Fortran, we
> overloaded it's linker internal tables and had to wait
> a couple of months for a patch. Then I ran into their
> zero init bug and gave up in disgust.

...

Pretty similar path from Philco-->CDC Cyber/Star-->DEC 10 -->VAX and
PDP's of various ilks --> period of embedded systems far removed from
any Fortran at all -->back to VAX -->PC OS/2 to --> NT4 (first MS OS
used "in anger")

The code base that got me to the Watcom compiler was moved from VAX to
OS/2 (Watcom) then to the DVF to move it to NT4. It doesn't have a user
interface other than terminal; I wrote a small demo and a proposal to
build one w/ Tcl/Tk but the client never funded the development.

I didn't do the OS/2 conversion from VAX but picked up a modification
and support and the move to NT4 (when also moved it from OW as the
client wanted a commercially supported compiler. (Of course, that DVF
morphed to CVF then shortly died is an ironic sidebar.) It's not as
large as yours (and I've never counted lines nor routines) but is a
suite of half-dozen multiple independent executables using shared memory
and semaphores to monitor plant performance on real time basis using
interface to plant control system and thermodynamics plant models for
heat rate, etc., as well as interactive analysis tools and a historian,
etc., etc., etc. No IDE here, either, I built onto the existing make
files and use the JPSoft command interpreters on MS (or used REXX on
OS/2) to build more sophisticated batch files for the compilation
process and the configuration management package for source control and
edit check-in/-out.

I've used the Visual Studio distributed with the DVF/CVF distribution
some for small projects or playing around but don't believe I would ever
willingly go that route on anything large; I can't stand the editor
limitations/idiosyncracies (vis a vis the different idiosynracies that I
_am_ used to :) ).

We've had at the Intel zero-init thing re: your code and the other
extensions used that aren't supported by other potential choices
otherwise ad nauseum in the past; I retired from active consulting not
too long after the time Intel bought the compiler group from Compaq and
the aforementioned project wasn't funded to provide any revenue so I've
never updated either Fortran/C compilers nor Matlab license since ...and
at this point don't expect to.

--

[user1]

Funny you mention TECO and RT-11. When I was in grad school, we had a
MINC-11 lab computer, with 8" floppies and all sorts of a/d and d/a
converters, digital i/o lines etc. I programmed it with RT-11 Fortran,
and a bunch of "call ipoke" and "call ipeek" to control and read data
from the instrumental contraption that I was hitched up to. TECO
probably, but I think there was also a keypad editor called KED.

[Fritz Wuehler]

Lynn McGuire <l...@winsim.com> wrote:

> Dont know. I'm an old mainframe hacker

* Bullshit Alert!!! *

Nobody who works on mainframes calls himself a hacker

> who moved to PrimeOS to Vax to Unix to PC.

That puts it in context. Not only didn't you belong in the mainframe world
but you exhibited bad judgement! ;-) Even MVS 3.8J is better than the best
UNIX or PC OS.

> We use Visual Studio exclusively for our user interface
> (600,000 lines of C++ code)

Is that 600K lines of GUI? Things are worse than I imagined.

[Lynn McGuire]

> We've had at the Intel zero-init thing re: your code and the other extensions used that aren't supported by other potential choices
> otherwise ad nauseum in the past; I retired from active consulting not too long after the time Intel bought the compiler group from
> Compaq and the aforementioned project wasn't funded to provide any revenue so I've never updated either Fortran/C compilers nor
> Matlab license since ...and at this point don't expect to.

The zero init port to non zero init has been just about
completed. The developer reported success right before
I threw some nasty bug reports at him. We may actually
get that project completed in the first quarter of 2012.
Then on to C++ !

Lynn

[E. S. Fabian]

I used to love TECO... and missed it on PC-s. I still use Brief, but I
cannot get its macro compiler to run under WinXP.
--
Steve

[dpb]

On 11/7/2011 9:28 AM, user1 wrote:
> Kevin G. Rhoads wrote:
...

>> I did too much of that for the Ph.D. thesis, ...
...

>> Still, it was less fuss than TECO and a homebrew runoff for RT-11 on
>> 8" floppies that I used to write the Master's. (Run through the daisy-wheel, change to the
>> Greek wheel and run it
>> through again. Joy.) I still have those floppies around, somewhere ...
>
> Funny you mention TECO and RT-11. When I was in grad school, we had a
> MINC-11 lab computer, with 8" floppies and all sorts of a/d and d/a
> converters, digital i/o lines etc. I programmed it with RT-11 Fortran,
> and a bunch of "call ipoke" and "call ipeek" to control and read data
> from the instrumental contraption that I was hitched up to. TECO
> probably, but I think there was also a keypad editor called KED.

You'se "kids" had it easy... :)

The BS/MS-level "PC" was the IBM 1620 w/ no i/o but punchcard in _and_
out; had to run the output deck thru the lineprinter (which had >50:50
shot of eating the deck causing to have to sign up for yet another 3AM
half-hour session to try to have output for 8AM lab)...

On the job (had moved from first employer and CDC shop but still well
before the IBM PC era), Princeton Plasma Physics Lab outsourced a
PDP11/45 w/ 256K and the wonders of wonders an actual Winchester
3rd-party 2(!!!) MB(!!!) hard drive. Three of us pooled resources and
bought it; ran RSX and DEC FORTRAN. The keyboard editor I recall was
EDT on VT100's extended keyboard. Took a separate 20A circuit to power
the three 19" racks plus the drive and rerouting a full A/C unit output
into the lab to keep temp's down to bearable. Heckuva' individual
machine at the time; roughly a third of the 11/780 in compute horsepower.

TECO on the PDP-10 was all that was available at the ORNL site,
however...try your name as command and see what happens... :)

--

[dpb]

On 11/7/2011 11:49 AM, E. S. Fabian wrote:
> I used to love TECO... and missed it on PC-s. I still use Brief, but I
> cannot get its macro compiler to run under WinXP.

TECO--type in name or other text and see what you get... :)

I can't use the compiler under XP, either, so I make sure to keep a
bootable partition around that will.

I had a problem w/ one of the XP fix-packs as well (or some other
update, was unable to ascertain which/what precisely was the culprit)
that broke the extended keyboard driver compatibility (D101key.drv)
which killed some of the extended keyboard functionality as well.

Fortunately, that problem healed itself when I rebuilt the system here
not too long ago so Brief is again fully functional here.

Anybody had any luck under newer MS OS--I've not updated the box and
haven't tried loading it on wife's new Thinkpad as a try-it and see
spearmint.

--

[E. S. Fabian]

dpb:

| On 11/7/2011 11:49 AM, E. S. Fabian wrote:
|| I used to love TECO... and missed it on PC-s. I still use Brief,
|| but I cannot get its macro compiler to run under WinXP.
|
| TECO--type in name or other text and see what you get... :)

Is TECO available on Intel architecture?

|
| I can't use the compiler under XP, either, so I make sure to keep a
| bootable partition around that will.

Unfortunately my system came without one, I did not spend the effort to
rebuild it...

| I had a problem w/ one of the XP fix-packs as well (or some other
| update, was unable to ascertain which/what precisely was the culprit)
| that broke the extended keyboard driver compatibility (D101key.drv)
| which killed some of the extended keyboard functionality as well.
|
| Fortunately, that problem healed itself when I rebuilt the system
| here not too long ago so Brief is again fully functional here.

except the compiler?

I hadn't such issues, only that of no compiler... But I had already created
my 146 compiled macros, and they do almost everything I want. The bigger
issue is not remembering a lot of them!
--
Steve

[dpb]

On 11/7/2011 12:15 PM, E. S. Fabian wrote:
> dpb:
>
> | On 11/7/2011 11:49 AM, E. S. Fabian wrote:
> || I used to love TECO... and missed it on PC-s. I still use Brief,
> || but I cannot get its macro compiler to run under WinXP.
> |
> | TECO--type in name or other text and see what you get... :)
>
> Is TECO available on Intel architecture?

Oh, surely _somebody_ has done it, but I'm not going looking... :)

> |
> | I can't use the compiler under XP, either, so I make sure to keep a
> | bootable partition around that will.
>
> Unfortunately my system came without one, I did not spend the effort to
> rebuild it...

I have a couple of old systems around that still have NT and OS/2
partitions just in case the former client ever would call about the
plant performance monitor system that can compile Brief macros on if
ever had the desire again. Doubt it will ever happen, but in my 40 yrs
of consulting every time I finally actually threw any client's stuff out
it never failed they would come to life again after as much as 10 years
of no contact and need something that could have done in much less time
if hadn't try to clean house. :(

...

> | Fortunately, that problem healed itself when I rebuilt the system
> | here not too long ago so Brief is again fully functional here.
>
> except the compiler?

Oh, yes. No, it didn't fix the problem w/ the compiler (or setup,
either, for that matter) not running under XP. The latter isn't a real
problem since one can always set the BFLAGS variable manually but w/o
the compiler there isn't any way to modify or update customized macros
other than compile on another system and move them over.

> I hadn't such issues, only that of no compiler... But I had already created
> my 146 compiled macros, and they do almost everything I want. The bigger
> issue is not remembering a lot of them!

Chuckle... :)

As noted, I never did actually figure out what killed the keyboard
driver; only that w/ a rebuilt system in is functional again.

I miss the old modifiable text modes, though. Graphical interface and
fonts are ok, but for coding the 100x43 and other choices were better
than simply making smaller fonts.

--

--

[dpb]

On 11/7/2011 1:40 PM, dpb wrote:
...

>> Is TECO available on Intel architecture?
>
> Oh, surely _somebody_ has done it, but I'm not going looking... :)

...

OK, I lied... :) It's cold and wet (well, damp anyway, which in itself
is novel in the midst of the extraordinary drought we're in) so I did a
little looking...

<http://almy.us/teco.html>

Dan Murphy published an article on early TECO in IEEE a couple years
ago; link is

<http://tenex.opost.com/anhc-31-4-anec.pdf>

and Dan's TECO page is at

<http://tenex.opost.com/>

Enjoy! :)

--

[E. S. Fabian]

dpb:

| I miss the old modifiable text modes, though. Graphical interface
| and fonts are ok, but for coding the 100x43 and other choices were
| better than simply making smaller fonts.

I used to use 132x60 or 80x75 mode when running Brief. Some of my video
cards had supported more than 60 lines even in 132-column mode, but Brief
did not. Under WinXP ntvdm.exe (or whatever else runs 16-bit code) limits me
to 80x50, which I find inadequate, though my eyesite not being what it used
to be, it is less eyestrain (and more headache). Because Brief really hogs
the processor, I usu. run it in full screen mode. My biggest gripe with
Brief on XP is unusability of LFNs. But using Take Command, the successor of
4DOS, 4OS2 and 4NT, reduces that particular pain.
--
Steve

[E. S. Fabian]

dpb:

|| Is TECO available on Intel architecture?

| OK, I lied... :) It's cold and wet (well, damp anyway, which in
| itself is novel in the midst of the extraordinary drought we're in)
| so I did a little looking...
|
| http://almy.us/teco.html
|
| Dan Murphy published an article on early TECO in IEEE a couple years
| ago; link is
|
| http://tenex.opost.com/anhc-31-4-anec.pdf
|
| and Dan's TECO page is at
|
| http://tenex.opost.com/

Thanks! I got all of TECO - now it's a questio of getting back the old
knack...
--
Steve

[Fritz Wuehler]

"E. S. Fabian" <ESFa...@zenge.org> wrote:

> I used to love TECO... and missed it on PC-s. I still use Brief, but I
> cannot get its macro compiler to run under WinXP.

If you use Linux you can probably build TECO from sources. It's still
available online. If you need it THAT badly you can run a Linux VM under
Windows. I used TECO as well, but love it? I don't think anybody loved
TECO. Punching cards took less concentration......

[dpb]

On 11/7/2011 4:31 PM, E. S. Fabian wrote:
...

> ... My biggest gripe with

> Brief on XP is unusability of LFNs. But using Take Command, the successor of
> 4DOS, 4OS2 and 4NT, reduces that particular pain.

Great minds think alike... :) I have the full JPSoft CD but am badly
out of date. I've not ever particularly cotton'ed to the TC processor
but use 4NT exclusively as the command processor.

Here's my .btm file that is what I use to invoke Brief. It handles the
transition of LFN transparently at the command prompt and at least so
far I've had no _known_ instance of it failing or causing any problems.

You're welcome to use any portion of it that suits or, conversely,
ignore it entirely. :)

@echo off
rem Batch file used as alias target for Brief invocation
rem Processes parameters recursively building a string
rem of short file names in local enviroment variable
rem bFileList and a string of command line parameters in
rem local enviroment variable bMacroList.
rem
rem Owing to limitation in DOS line length, if file is not
rem specified with specific path information, only the filename
rem itself is provided, otherwise the fully qualified sfn string
rem is used. This may be overkill for specifying the file,
rem but I didn't want to add additional logic at this time....
rem Note Bene: the following is sorta a trick....
rem %@path[%bpath] returns root directory (including trailing "\")
rem pointing to where brief.exe resides....Brief install uses
rem env variable bPath to point to the Brief macros subdirectory...

setlocal
unset /q bFileList
unset /q bMacroList

rem %# returns number of command line parameters
rem set p_i=%[%i] sets variable p_i to ith parameter.
do i = 1 to %#
set p_i=%[%i]
iff "%@left[1,%p_i]" == "-" then
set bMacroList=%bMacroList %p_i
else
iff %@len[%@path[%p_i]]=0 then
iff exist %p_i then
set bFileList=%bFileList %@filename[%@sfn[%p_i]]
else
set bFileList=%bFileList %p_i
endiff
else
set bFileList=%bFileList %@sfn[%p_i]
endiff
endiff
enddo
%@path[%bpath]b.exe %bFileList %bMacroList
unset /q bFileList bMacroList
endlocal
quit

[Kevin G. Rhoads]

>Punching cards took less concentration......

Yeah, but then the publically available keypunches often had the star-wheels (for reading the
card on the drum) mangled because of idiots who ripped the darn thing out without disengaging ....
(Considering the size of the metal bar interlock on the drum, I considered that a further indication
of Neaderthality of the perpetrator of that egregious damage.)

And then usually only the 026s were open, all the 029s were tied up.

But Hollerith cards were still easier to deal with than paper tapes, IMHO.

[Kevin G. Rhoads]

>had to run the output deck thru the lineprinter

Well if you've got a lister somewhere, I still have my SysHak deck.

(Back when I was young and stupid^H^H^H^H^H^Hinexperienced I wrote a
how-to guide for hacking OS/360 (freshman year, 69/70) and learned
all about "shoot the messenger")

While I have greenbar as well as the deck, I'm too busy doing stuff
to type it back in. But I'd love to post it to scribd, maybe for
the 50th anniversary ...

[E. S. Fabian]

Kevin G. Rhoads:

Easier - until you dropped the deck... Of course, if they had serial
numbers, AND you had a card sorted available, that was not a problem,
either. Until the number of cards exceeded the size of the 10 stackers.

On one project I used an editor on a time-shared system to maintain the
source code, used the gangpunch to punch the 3,000 or so cards of my source
code, put them in a card drawer, and lugged the drawer full of cards to the
other building where the Univac AN-UYK 7 computer was located which was my
development target. My code was designed to program the programmable sonar
data processor my company was building, so to test that the data through the
interface was what I expected I added a lot of code to create octal dumps
under control of an option switch. My boss (a logic designer, with no
software background) had objected to the time spent on this debug code.
Guess what? When the customer's technical rep. came to see the program in
operation, first question was "How do you know the interface data is what is
planned?" and had me generate a 3-inch high stack of 11x14.875 printout to
take back to the other coast for verification study...
--
Steve

[dpb]

I have access to no hardware any longer--kept the PDP11/45 for years and
years and years but finally donated it to a former DEC employee (whom
I've not seen in nearly 30 years now; now idea if he still has the
collection or not). Finally tore the guts out of the old Philco 7-track
tape drives and scavanged the cabinets for tool storage, etc., about 15
yr ago. The VT100s, DECWriters, and all the rest went the way of all
good Silent 700's over the ages...

I had finished BS and gone to gainful employment while working on MS
thesis at the time you were in trouble above... :)

That was the period was involved in moving large nuclear design code
base from the Philco 2000 series to make the move to CDC 6600 and began
to appreciate reasons for trying to write at least moderately portable
FORTRAN (or any other code) as opposed to using every possible
machine-dependency possible as was general practice at the time. While
obviously impossible completely we did at least begin to actually
modularize and factor the dependencies into isolatable chunks for future
generations' benefit...

--

[Lynn McGuire]

We used to love to 60 bit word size on the old 6600
and 7600. Would forgive a lot of sins before double
precision was available on the Univac 1108 (was 36
bit word).

Lynn

[dpb]

On 11/8/2011 10:55 AM, Lynn McGuire wrote:
> On 11/8/2011 8:04 AM, dpb wrote:

...

>> ... from the Philco 2000 series to make the move to CDC 6600

...

> We used to love to 60 bit word size on the old 6600
> and 7600. Would forgive a lot of sins before double
> precision was available on the Univac 1108 (was 36
> bit word).

...

Indeed. The Philco 2000 was a 48-bit word and for a while the highest
performing scientific machine commercially available. Philco was bought
up by Ford and while Ford certainly had the resources, management
decided it wasn't in their future to continue to compete w/ IBM in
general purpose computing and towards end of the 60s, all projects for
future systems were halted and only support for the existing
installations continued. I forget the exact year the plug was finally
pulled on the Philco and we transitioned fully to CDC.

At one point I attended an ANS (American Nuclear Society) annual meeting
and amongst sessions attended was one on reactor excore power detector
issues. A MS candidate from a Big-10 school presented results of his
thesis, a point kernel model partially funded by a competing PWR vendor.
I happened to be working on a model at the time for some different
internal needs, but was able to get a copy of the model from the student
as his advisor wanted to be able to say they had a model that worked on
both IBM and CDC hardware.

So, I took the FORTRAN source, made a few necessary system-dependent
changes to compile it and ran the supplied test data through it.
Answers were absolutely nothing whatsoever like those presented at the
conference nor those runs on which the thesis was based. Turned out the
single precision underflow in the exponentials occurred so near the
physical outer dimensions of the reactor core they were still quite
significant in influence on the actual response of an excore detector
but weren't reflected in the lower precision model. Converting to
DOUBLE PRECISION on the IBM solved the problem.

Turned out, fortunately, in the end that the results he got with the
revised code were even in more generally good agreement with those
previously obtained on a global scale so he got his degree on time but
had to revise the dissertation after he came to work for me. :)

--

[Lynn McGuire]

I have long maintained that the 32 bit words on IBM
mainframes were too small for serious engineering
work. I believe that the 32 bit words have caused
significant problems all over the place. Including
integer overflows even on the Unix time clock:
http://en.wikipedia.org/wiki/Year_2038_problem

Lynn

[E. S. Fabian]

Lynn McGuire:
| ...

| I have long maintained that the 32 bit words on IBM
| mainframes were too small for serious engineering
| work. I believe that the 32 bit words have caused
| significant problems all over the place. Including
| integer overflows even on the Unix time clock:
| http://en.wikipedia.org/wiki/Year_2038_problem

Soon after transitioning to IBM/360+ mainframes I learned that to do
anything useful in floating point, I needed to use double precision... Esp.
because the base-16 exponent field stole another 3 bits from the precision.

IMHO the invention of the 8-bit byte and word lengths that are powers of 2
created a great step backwards in scientific and engineering calculations.
You either use insufficient wordlength, or overkill. From my experience
using a 12-bit byte as the basis. 24b integers suffice almost everywhere,
48b integers for the US national debt in cents, and likewise, 48-bit is
sufficient precision for most floating point work.

The old 36b machines wre better in this respect!
--
Steve

[Kevin G. Rhoads]

>IMHO the invention of the 8-bit byte and word lengths that are powers of 2
>created a great step backwards in scientific and engineering calculations.
>You either use insufficient wordlength, or overkill. From my experience
>using a 12-bit byte as the basis. 24b integers suffice almost everywhere,
>48b integers for the US national debt in cents, and likewise, 48-bit is
>sufficient precision for most floating point work.
>
>The old 36b machines wre better in this respect!

Strongly seconded. 8 bit bytes, 32 bit words were numerology over common sense.

[Lynn McGuire]

Yup. They should have gone with 8 bit bytes and
48 bit words at a minimum. Oh well, the world is
transitioning to 64 bit words as we speak.

Lynn

[Lynn McGuire]

Hard drives need 48 bit pointers as of 100 GB ?

Lynn

[Fritz Wuehler]

> I have long maintained that the 32 bit words on IBM
> mainframes were too small for serious engineering
> work. I believe that the 32 bit words have caused
> significant problems all over the place. Including
> integer overflows even on the Unix time clock:
> http://en.wikipedia.org/wiki/Year_2038_problem

Yeah but IBM had 128 bit floating point since System 360 in the 1960s. What
more did you need? The word size has nothing to do with floating point
capabilities, the only thing you didn't have back then was a double
precision 64 bit integer. BTW they put men on the moon with those 32 bit IBM
machines. Don Adam's "missed it by THAT much" hadn't been invented yet ;-)

[Kevin G. Rhoads]

>Yeah but IBM had 128 bit floating point since System 360 in the 1960s.

They had quad on the 360s? Not what I remember, but it has been a while.

I remember 32 bit singles and 64 bit doubles, with that weird hex exponent
stuff, not 128 bit quads ... at least not in hardware. And not all of the
360s had hardware float support, it was standard in the high end models,
but an option on the lower.

Using the 32 bit floats often took care to get the right answer, and
even with hardware float support, double precision was (IIRC) slower,
not much slower, but slower. And if you had to use to software implementations,
then it was significantly slower.

I don't think the 20/25 even offered hardware float support, the 20
lacked a lot. The 360/30 was the lowest end that had all the core
instruction set implemented. Then float was one option and there was an
extended business set of instructions that could be implementd in hardware
as an option also.

Special hardware options included 1401/1410 emulation, IIRC, available only
on the 360/40 and 7090/7094 emulation available for the 360/65.

But the 360 core instruction set was not all implemented in hardware, some
was microcoded, and some was not implemented at all in hardware unless you
opted for the various hardware options. Unimplemented instructions trapped
to software simulations inside the OS kernel (again, IIRC).

But I didn't think the 360 line offered quad precision floats as an option
even in software implementation, and I don't think the 370s did either. That
came later (IIRC).

[Lynn McGuire]

When one had integers and floating point equivalenced like
we did in our dynamic memory system that we installed in
1978, we could not move to double precision until we
could use a union due to corresponding lack of integer*8.
That hurt us more than we realized.

Lynn

[Nomen Nescio]

"Kevin G. Rhoads" <kgrh...@alum.mit.edu> wrote:

> >Yeah but IBM had 128 bit floating point since System 360 in the 1960s.
>
> They had quad on the 360s? Not what I remember, but it has been a while.

I remembered wrong, the 360 did not support extended floating point (I need
to check the 360/91 if I can find the doc) but the 370 POPs specifies
extended format 128 bit operands and the assembler supports defining storage
or constants with format L.

> I remember 32 bit singles and 64 bit doubles, with that weird hex exponent
> stuff, not 128 bit quads ... at least not in hardware. And not all of the
> 360s had hardware float support, it was standard in the high end models,
> but an option on the lower.

The POPs shows it's specified in hardware on the 370. On the 360 I cannot
find it and I believe what I said earlier was incorrect. Sorry for the
error.

> But I didn't think the 360 line offered quad precision floats as an option
> even in software implementation, and I don't think the 370s did either.
> That came later (IIRC).

The 370 POPs GA22-7000-4 (Sept. 1975) says on p. 16 Floating-Point Registers

Four floating-point registers are available for floating point
operations. They are identified by the numbers 0,2,4, and 6 (see
illustration). Each floating-point register contains 64 bits and contain
either a short (32-bit) or long (64-bit) floating point operand. A short
operand occupies the high-order bit positions of a floating-point
register. The low-order portion of the register is inored and remains
unchanged in arithmetic calling for short operands. Two pairs of adjacent
floating-point registers can be used for extended operands: registers 0,2,
and registers 4,6. Each of these pairs provides a 128-bit format.

(any typos in above are mine)

P. 290 discusses the format of the operands including the 128 bit "extended
format" and shows the range (which is horribly tiny btw!).

I don't remember when System 370 came out and the POPs I saw may not be the
first POPs for the 370. In other words, 1975 indicates the date of the copy
I have but it may not be an indication of when the 128-bit facility was
available, other than as a not later than date.

[Kevin G. Rhoads]

>The POPs shows it's specified in hardware on the 370.

I didn't know that, but it is good to know. Thanks for the additional information.