RSTS/E AWS progress…continued

I ended yesterday on a good note. Looking back at the program I see there was no valid FIELD statements. Actually it looks like this…

LIST 130
TAPE01 12:01 AM 29-May-99
130 ! FIELD !1%, (I%-1%)*32% AS D$, 27% AS B$, 5% AS A$

Ready

LIST 140
TAPE01 12:01 AM 29-May-99
140 ! TEST FOR MULTI LINE “&”

Ready

LIST 150
TAPE01 12:01 AM 29-May-99
150 FIELD !1%, (I%-1%)*164% AS FILL$

Ready

Line 150 should have a # after the FIELD statement. Somewhere along the line I must have done a search and replace. So of course printing FILL$ would print a blank line.

A reminder…

$ ./tapedump INPUT: CUST-TAPE-1000.aws
TAPEDUMP v1.0 (BASIC) copyright Jay Moseley, CCP 2000
Processing AWSTAPE file: CUST-TAPE-1000.aws
Serial Number from VOLume 1 label: VOL001
File MVT Dataset RECFM BLKSIZE LRECL BlocksExpected BlocksRead
0001 CUSTOMER.FILE B    16,400   164             10         10

OK. After some trial and error here is where I’m at…

sim> att tu -r -f aws CUST-TAPE-1000.aws

ASSIGN MM0:

OLD TAPE01

Ready
        
RUN
TAPE01  12:56 AM        29-May-99
 1                                                                      
                                                                        
                                  
 2                                                                      
                                                                        
                                  
 3                                                                      
                                                                        
                                  
 4                                                                      
                                                                        
                                  
 5                                                                      
                                                                        
                                  
 6                                                                      
                                                                        
                                  
 7                                                                      
                                                                        
                                  
 8                                                                      
                                                                        
                                  
 9                                                                      
                                                                        
                                  
 10                                                                     
                                                                        
                                  
 11           tsqsxuyutrwtrxyxqETT@@@@@@C$#(@@@@@@@Y@@@@@@@@@G@@@@@@@@@@
@@@@@@@@@QY@@@@@@qyvr`ps`pvqyyp`pw`qwpquKrwwtrt@f@yr@D@@@@@@@@@G@@@@@@@
@@@WAqwswu@
 12           tsqsyxtywxqvwxrruBT@@@@@@@@Q@@@@@@@@@@@@@@@@@@@@@@@@@C$@@@
@@@@@@@@@@@@@@@@@@@@@@@@@qywv`qq`qxrpqr`py`rrpytKrvvxq@b@sxx@c@@@@@@@W#@
@@@@@@@@@@@TEptqrt@
 13           tsqswupywvtupsqvuAFT	""@@@@T	@@@@@@@@@@@@D@@@@@@@@@@U	@@@@@@@
@@@@@@@@@@@@@@@@@@@@qywq`pt`ryqyyv`qr`qwpuvKuqtvsu@E@tyx@D@@@@@@@C$$"@@@
@@@@@@@@@VHtsrpw@

[records 14-79 deleted to keep this shorter]

 80           tsqsuyqxqsvvrvuyrDT@@@@@@@@E#@@@@@@@@@S@@@@@@@R"(@@@@@@@@@
@@@@@@@@@@@@@@@@qyqu`pt`pvqysu`pq`rqpuyKspurrr@b@uvr@f(@@@@@@TC$@@@@@@@@
@@@@@TVvuwpq@
 1020 
 11 

Ready

Hopefully that garbage is EBCDIC!
I assume records 1-10 are the AWS header record. I don’t remember the format. So it’s easier to assume!
I assume the 1st actual record above is #11

Now to use my EBCDIC conversion routine, I wrote earlier.

Now I’m rerunning the above program and getting totally different output.