BMD program conversion and data puzzle question
Terence
and IBM 360 Fortran H to (initially F77 and later) F90. I was kindly
pointed to these, stored as copied PDP-20 DECUS magnetic tapes at
http://pdp-10.trailing-edge.com/decuslib20-05/01/decus/
under file set 137 way doen under "PDP-20".
1) BMD04D.FOR is missing; I would appreciate being pointed to any
source of this.
I think it will turn out to be a simple sample analyser that uses
12-bit binary coded data, similar to that used by the IBM survey
analysis program of 1972 (And upon which I may be the last living
expert).
2) two or three programs in the BMDXnn series (of 58 total) have
subroutines only partially complete at the end but these routines are
very probably the same or similar to others that are complete. Most of
this series are sequence-numbered on the left instead of the right!
And they contain binary zeroes, one extra TAB per line, and the lines
are only line-feed terminated!!!
3) For the interested, I propose to make available on our web-site all
recovered, corrected source versions, and a list of what they do and
some documentation.
For the self-starter, any reference to subroutine TPWD should be
removed as it is a JCL-related file-to-I/O unit matcher, but the
(card) input is always unit 5 and output(printer) is always 6
I have just tested a needed additional module to pick up the file
names of units 5 and 6 from the command line, which also allows one
menu program to select and call any program modules and pass the file
names.
4) All programs seem to compile with DVF6.6.1 in the (corected)
original form.
All tested programs run the test decks correctly, but they include 6-
byte ascii strings in double-precision (whatever that now means)
floating point variables which I am replacing with character*6.
MS F77 has a problem with FORMAT(12G) and hollerith data
initialization of floating point used for text, both of which SEEM to
be valid.
Introduction over! Now the question:-
These programs were written as punched card source.
The programs, but not the test data has been converted to ascii.
Most of the test data is easy to fix:
% becomes (
< becomes )
# becomes =
& becomes +
(always except in the "binary" data!)
and (I think) an = becomes single apostophe
However, can anyone make sense of these strings ending in "P" and "S"
in this test deck?
I suspect the basis in EBCDIC. I suspect the program is treating each
character as IBM punch codes for statistical analisis and checking all
possible patterns are included.
_ is the 11 bit, & is the 12-bit, 1 to 7 are uniquely bit 1 to 7. And
&,-,0, 8 and 9 can stand alone or be used in combination with ONE of
1-7. This allows forming 12 bits in any combination. Yes, I know it's
a keyboard sequence of some kind!
But some codes below SEEM to be unexpectedly repeated
PROBLM TEST02 80
3
%80A1<
1234567890#,$.-0&:<)('123&;}]:=456{_#^%789=%*<-/
QWERTYUIOPASDFGHJKLZXCVBNM,. P
1234567890#,$.-0&:<)('123&;}]:=456{_#^%789=%*<-/
QWERTYUIOPASDFGHJKLZXCVBNM,. P
1234567890#,$.-0&:<)('123&;}]:=456{_#^%789=%*<-/
QWERTYUIOPASDFGHJKLZXCVBNM,. P
PROBLM
TEST03
1234567890123456789#,$.-0123&=%*<-/QWERTYUIOPASDFGHJKLZXCVBNM89&-.$,##,
$. S
1234567890123456789#,$.-0123&=%*<-/QWERTYUIOPASDFGHJKLZXCVBNM89&-.$,##,
$. S
1234567890123456789#,$.-0123&=%*<-/QWERTYUIOPASDFGHJKLZXCVBNM89&-.$,##,
$. S
FINISH
user1
[snip]
Could it be model 026 versus 029 keypunch code differences.
Here is a translation table snatched from the web -
; TRANSLATE TABLE USED ON INPUT TO TRANSLATE 026 CODES TO 029 CODES.
KP2629: .BYTE ' ,'! ;THESE DON'T CHANGE.
.BYTE 134 ;QUOTE(") BECOMES "\".
.BYTE 075 ;"#" BECOMES "=".
.BYTE '$ ;THIS DOESN'T CHANGE.
.BYTE 050 ;"%" BECOMES "(".
.BYTE 053 ;"&" BECOMES "+".
.BYTE 136 ;APOSTROPHE (') BECOMES "^".
.BYTE 135 ;"(" BECOMES "]".
.BYTE 133 ;")" BECOMES "[".
.BYTE '* ;THIS DOESN'T CHANGE.
.BYTE 074 ;"+" BECOMES "<".
.ASCII ",-./0123456789";THESE DON'T CHANGE.
.BYTE 137 ;":" BECOMES "_".
.BYTE 076 ;";" BECOMES ">".
.BYTE 051 ;"<" BECOMES ")".
.BYTE 047 ;"=" BECOMES "'".
.BYTE 043 ;">" BECOMES "#".
.BYTE 045 ;"?" BECOMES "%".
.ASCII "@ABCDEFGHIJKLMNOPQRSTUVWXYZ";NO CHANGE.
.BYTE 077 ;"[" BECOMES "?".
.BYTE 073 ;"\" BECOMES ";".
.BYTE 072 ;"]" BECOMES ":".
.BYTE 046 ;"^" BECOMES "&".
.BYTE 042 ;"_" BECOMES QUOTE (").
Terence
user1 wrote:
>
> Could it be model 026 versus 029 keypunch code differences.
> Here is a translation table snatched from the web -
>
> ; TRANSLATE TABLE USED ON INPUT TO TRANSLATE 026 CODES TO 029 CODES.
Etc
By George he's got it! (Paraphrasing G.B.Shaw in Pygmalion).
I was hunting fo my "BIg Blue" little blue fold-up card for EBCDIC
codes, but yes! It's 026 vs 029 card punch. since the programming and
testing was originally done about 1961 and the 029 was I think a
little later.
Thanks!
user1
Retro computing for sure.
It happened to me in the early 80's. Somebody at LANL sent our research group
the source code for a fortran program, punched with 026 code. When we put it
through are card readers, which assumed 029 code, it looked a bit funny.
Terence
user1 wrote:
> Retro computing for sure.
>
> It happened to me in the early 80's. Somebody at LANL sent our research group
> the source code for a fortran program, punched with 026 code. When we put it
> through are card readers, which assumed 029 code, it looked a bit funny.
It's hard work, but what I get out of it, is a tested algorithm for
each problem type.
It also refreshes my grey cells, when I don't have my fifties Univ.
notes any more.
All the recent books I checked refer the reader to "standard
statistical packages" and never seem to show any algorims or even
equations, nor mention that there exist different ways of achieving
these calculations, with pros and cons between them..
M.J. Moroney's "Facts from Figures" has some hand-worked exanples.
The best references I have found that really give details are several
really ancient books from the days of hand-cranked mechanical
computers, which methods wisely tend to incorporate parallel error
accumulation and checking tables during the calculations.
Just remembered; as youngsters in the forties, we we given
triangulated observations of meteor paths and self-checking algorithms
(as above), to locate the actual tracks in space of each "shooting
star" in order to aid astronomers to assign showers to specific or
even unknown comets. Perhaps that's why I took up mathematics. Cunning
teachers!
Glen Herrmannsfeldt
> I am converting the BMD statistical program source from Fortran IV,
> and IBM 360 Fortran H to (initially F77 and later) F90. I was kindly
> pointed to these, stored as copied PDP-20 DECUS magnetic tapes at
> http://pdp-10.trailing-edge.com/decuslib20-05/01/decus/
> under file set 137 way doen under "PDP-20".
(snip)
> Introduction over! Now the question:-
> These programs were written as punched card source.
> The programs, but not the test data has been converted to ascii.
> Most of the test data is easy to fix:
> % becomes (
> < becomes )
> # becomes =
> & becomes +
> (always except in the "binary" data!)
> and (I think) an = becomes single apostophe
I have a table of punch codes for Fortran I. Letters and numbers
haven't changed. Those are 36 out of 48 characters.
character punch
= 8-3
- 8-4
+ 12
. 12-8-3
) 12-8-4
- 11
$ 11-8-3
* 11-8-4
/ 0-1
, 0-8-3
( 0-8-4
Notice that there are two - punch codes. The manual explains that only
the 11 punch - is allowed in Fortran source, but both are allowed in
input data.
I don't see any that might accidentally become P (11-7) or S (0-2)
-- glen
Terence
Glen Herrmannsfeldt wrote:
(snip)
>
> character punch
> - 8-4
...
> - 11
> Notice that there are two - punch codes. The manual explains that only
> the 11 punch - is allowed in Fortran source, but both are allowed in
> input data.
>
> I don't see any that might accidentally become P (11-7) or S (0-2)
>
No, The P and S rows are just labeled as such to identify the test.
The characters before those are the test characters.
But, Good point! I didn't spot the two versions of a minus sign.
Strictly, one, the" &", is a "zone punch" in IBM card code, but
still...