Dumb beginner question... 
Author Message
 Dumb beginner question...

I know, I'm nuts.  But at 40, I'm trying to become an assembler
programmer (hey, what can I say, they posted the job).

I just can't seem to get this....

When you load an address of a storage area into a register, it's the
address of the address, right?  What I'm doing is examining every byte
of a record, to see if there are 4 commas (may be other characters
inbetween), followed by 5 numbers, which are immediately followed by a
comma:

    ,dizoy,*,s46oihd  ,,12345,lskdfyuasdf,

These are variable length records, so what I did was figure the endrec
when I do the get for the RPL.  But it's not working.

The RPL's area is LIQAREA, a fullword.

I am using (Yes, I bet a BCT would be easier, but I want to solve this
first):

          L    R6,LIQAREA
COMMA1    CLI  0(1,R6),X'6B'
          BNE  COMMA1
          LA   R6,1(R6)
COMMA2    CLI  0(1,R6),X'6B'
          BNE  COMMA2
          LA   R6,1(R6)
COMMA3    CLI  0(1,R6),X'6B'
          BNE  COMMA3
          LA   R6,1(R6)
COMMA4    CLI  0(1,R6),X'6B'
          BNE  COMMA4
          LA   R6,1(R6)

Now, using XRAY, this is finally working (dumb mistake, fixed it),
but, when I get to the next part, this is where I 'die'.

         TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)
         BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

I am guessing that I am looking at the address in R6, or the beginning
of the storage area.  Should I be using LIQAREA to loop through for
the commas so I'm pointing in the correct location?

I feel REALLY dumb asking this, but I just can't seem to see it.  (And
no, I haven't been doing this long)

Thanks.



Mon, 07 Mar 2005 11:03:25 GMT  
 Dumb beginner question...

Quote:

>I know, I'm nuts.  But at 40, I'm trying to become an assembler
>programmer (hey, what can I say, they posted the job).

>I just can't seem to get this....

>When you load an address of a storage area into a register, it's the
>address of the address, right?  What I'm doing is examining every byte

No.  If you use a LA and the second operand is the name of the storage
are, then the register receives the address of the area, not the
address of an address.

Quote:
>of a record, to see if there are 4 commas (may be other characters
>inbetween), followed by 5 numbers, which are immediately followed by a
>comma:

>    ,dizoy,*,s46oihd  ,,12345,lskdfyuasdf,

Since this example has 5 commas before the numbers, it is not
surprising that you code rejects it.

Quote:

>These are variable length records, so what I did was figure the endrec
>when I do the get for the RPL.  But it's not working.

>The RPL's area is LIQAREA, a fullword.

What does RPL mean and how is LIQAREA defined.

Quote:

>I am using (Yes, I bet a BCT would be easier, but I want to solve this
>first):

>          L    R6,LIQAREA
>COMMA1    CLI  0(1,R6),X'6B'
>          BNE  COMMA1
>          LA   R6,1(R6)

All of these loops are missing code to detect running out of data.

Quote:
>COMMA2    CLI  0(1,R6),X'6B'
>          BNE  COMMA2
>          LA   R6,1(R6)
>COMMA3    CLI  0(1,R6),X'6B'
>          BNE  COMMA3
>          LA   R6,1(R6)
>COMMA4    CLI  0(1,R6),X'6B'
>          BNE  COMMA4
>          LA   R6,1(R6)

>Now, using XRAY, this is finally working (dumb mistake, fixed it),
>but, when I get to the next part, this is where I 'die'.

>         TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)

It would help to see how TRT_TABLE is initialized.

Quote:
>         BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

>I am guessing that I am looking at the address in R6, or the beginning
>of the storage area.  Should I be using LIQAREA to loop through for
>the commas so I'm pointing in the correct location?

>I feel REALLY dumb asking this, but I just can't seem to see it.  (And
>no, I haven't been doing this long)

>Thanks.

<<Remove the del for email>>


Mon, 07 Mar 2005 12:07:44 GMT  
 Dumb beginner question...



Quote:
> I know, I'm nuts.  But at 40, I'm trying to become an assembler
> programmer (hey, what can I say, they posted the job).

> I just can't seem to get this....

> When you load an address of a storage area into a register, it's the
> address of the address, right?  What I'm doing is examining every byte
> of a record, to see if there are 4 commas (may be other characters
> inbetween), followed by 5 numbers, which are immediately followed by a
> comma:

>     ,dizoy,*,s46oihd  ,,12345,lskdfyuasdf,

> These are variable length records, so what I did was figure the endrec
> when I do the get for the RPL.  But it's not working.

> The RPL's area is LIQAREA, a fullword.

> I am using (Yes, I bet a BCT would be easier, but I want to solve this
> first):

>           L    R6,LIQAREA
> COMMA1    CLI  0(1,R6),X'6B'

I think our HLA won't even accept that, CLI doesn't have a length field.

Quote:
>           BNE  COMMA1

And this would be an infinite loop. I suspect you have posted out-of-date
code, which will not make things easier.

- Show quoted text -

Quote:
>           LA   R6,1(R6)
> COMMA2    CLI  0(1,R6),X'6B'
>           BNE  COMMA2
>           LA   R6,1(R6)
> COMMA3    CLI  0(1,R6),X'6B'
>           BNE  COMMA3
>           LA   R6,1(R6)
> COMMA4    CLI  0(1,R6),X'6B'
>           BNE  COMMA4
>           LA   R6,1(R6)

> Now, using XRAY, this is finally working (dumb mistake, fixed it),
> but, when I get to the next part, this is where I 'die'.

>          TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)
>          BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

What is in TRT_TABLE? If you can post that it might help.

John Homes



Mon, 07 Mar 2005 12:42:59 GMT  
 Dumb beginner question...
[ posted and emailed ]



Quote:
>          L    R6,LIQAREA

You don't show enough for us to know whether you're loading register 6
correctly...

Quote:
>COMMA1    CLI  0(1,R6),X'6B'

There's no length field in a CLI instruction.  Also, stylistically, if
you're looking for a comma, it's better to state it that way in your
instruction.  Thus:    CLI   0(R6),C','

Quote:
>          BNE  COMMA1

You need to adjust your loop variable each time through the loop...

Quote:
>          LA   R6,1(R6)

... and check the adjusted value to ensure it's within range before using
it.

Those problems were repeated a few times.

Quote:
>         TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)

R6 points to the comma you found, right?  That's not numeric.  If you want
to test the five characters after the comma, use  TRT   1(5,R6),TRT_TABLE

Quote:
>         BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

BC   6 is almost certainly the wrong condition code mask.

TRT return three different return codes: zero if all bytes were translated
without a non-zero lookup result, one if there was a non-zero lookup result
while additional bytes remained, and two if the source field was exhausted
at the same time a non-zero lookup occurred (that is, the last byte of the
source field produced the non-zero lookup).

Your BC   6    will fall through with  a 1 condition code, and thus treat a
field containing a non-numeric character before the last byte as though it
contained all numeric characters.

Unless you specifically care about the last-byte / not-last-byte
determination, you should generally use  "BNZ"  to branch if a non-zero
lookup occurred, and "BZ" to branch if the data was clean (all zeros
returned from the lookups).

--



Mon, 07 Mar 2005 17:14:11 GMT  
 Dumb beginner question...
Ough!
S{*filter*}most of this code and start looking at the TRT instruction again
(if you feel comfortable with that one - it is one of the more challenging
facitilities in the 370 architecture)

I believe the POP still has sample code using TRT for parsing.
What you can do is something like this:

 LA R1,AREA-1  point just before the area to be parsed
 SR R2,R2   clear this register, it receives entries from the TRTABLE
 LA R3,(L'AREA-1)(R1)   set address in register for calculating length
PARSE1 EQU *
 LR R4,R3   copy address
 SR R4,R1   calculate length property for TRT
 BM COMPLETE  branch if nothing more to parse
 EX R4,PARSE  get address of next special character in R1
 BZ COMPLETE  branch if no special character was found
 B  *(R2) branch to process the special character found
 B PROCESS4 branch to process character(s) code 4 in TRTABLE
 B PROCESS8 branch to process character(s) code 8 in TRTABLE
* one such line for every possible entry in TRTABLE
PARSE   TRT 1(0,R1),TRTABLE  executed instruction
PROCESS4 EQU * for instance comma detected
* do whatever needed when R1 points to the next comma
 B PARSE1 branch back when finished with code 4
PROCESS8 EQU * some other character detected
* do whatever needed when R1 points to some other special character
 B PARSE1 branch back when finished with code 8

Your TRTABLE must have 256 zeroes except for the special characters
you want to detect: X'04' for comma, X'08' for some other and so on.

Depending upon how you get access to the AREA you may need to
get its address into R1 and decrement it (BCTR R1,0) and get its
length into R3, decrement and finally add R1.

BTW, you just cannot work with IBM assembly language without
the POP (short for Principles of Operation). There you find a
thorouogh explanation of every machine instruction available and
quite a few examples as well. Most of your questions will be
answered in that book.

If after this you still want to look again at your own code:
All your CLI/BNE tests will loop forever unless you happen
to have only commas in your buffer. You do not increment
your pointer within each test loop.

And BC 6 after a TRT instruction will branch unless the
TRT found nothing but zeroes in the TRTABLE

regards Sven



Quote:
> I know, I'm nuts.  But at 40, I'm trying to become an assembler
> programmer (hey, what can I say, they posted the job).

> I just can't seem to get this....

> When you load an address of a storage area into a register, it's the
> address of the address, right?  What I'm doing is examining every byte
> of a record, to see if there are 4 commas (may be other characters
> inbetween), followed by 5 numbers, which are immediately followed by a
> comma

>     ,dizoy,*,s46oihd  ,,12345,lskdfyuasdf,

> These are variable length records, so what I did was figure the endrec
> when I do the get for the RPL.  But it's not working.

> The RPL's area is LIQAREA, a fullword.

> I am using (Yes, I bet a BCT would be easier, but I want to solve this
> first):

>           L    R6,LIQAREA
> COMMA1    CLI  0(1,R6),X'6B'
>           BNE  COMMA1
>           LA   R6,1(R6)
> COMMA2    CLI  0(1,R6),X'6B'
>           BNE  COMMA2
>           LA   R6,1(R6)
> COMMA3    CLI  0(1,R6),X'6B'
>           BNE  COMMA3
>           LA   R6,1(R6)
> COMMA4    CLI  0(1,R6),X'6B'
>           BNE  COMMA4
>           LA   R6,1(R6)

> Now, using XRAY, this is finally working (dumb mistake, fixed it),
> but, when I get to the next part, this is where I 'die'.

>          TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)
>          BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

> I am guessing that I am looking at the address in R6, or the beginning
> of the storage area.  Should I be using LIQAREA to loop through for
> the commas so I'm pointing in the correct location?

> I feel REALLY dumb asking this, but I just can't seem to see it.  (And
> no, I haven't been doing this long)

> Thanks.



Mon, 07 Mar 2005 17:38:35 GMT  
 Dumb beginner question...
Just a few general hints. The solution of your problem is quite
simple, several people have already pointed out some of them, actually
there are countless!

First of all, Let's get to the RPL. This macro allows to work in two
modes, a MOVE mode in which you make a record reading directly into a
work area of your own, for example get RPL=MY_RPL,MY_AREA so your
record is filled after each reading with new data. Last but not least
RPL's can work in a LOCATE mode, in this mode(Which you are using in
your exercise) you work directly in the i/o buffer, the address of
this buffer should be in the label you provided under the subparm LOC
of the rpl, so better do not forget to do this!. I am assuming you did
it properly since you are mentioning an area called LIQAREA. In both
cases you should also provide an EXLST to handle EOF conditions
properly (That is, whenever EOF occurs a 'goto' this label will
occur).

Next in the list is the parsing, so after you read a record you have a
starting area where to start parsing from, whichever way you use to
parse the commas is your call, in your example it seems that you are
looking for consecutive ones, since you are comparing each character
right after the beggining. Personnaly I would use a TRT to detect the
commas, jump over one character and loop four times, with the proper
error handling if the condition you seek are not met, but you will
figure this out for yourself. The way to set a TRT has been already
explained, set up a 256 zeroes out and change to 01 the commas, a
quick way to set up such a table may be:

TRT_COMMAS   dc  256x'00'
             org TRT_COMMAS+C','
             dc  x'01'
             org

Once you made that you have half the way made, you need to chack for
numerics, which is basically the same problem as with commas!. So
assuming the numerics are numeric characters(They may be packed or
BCD!) set up a new table like this:

TRT_NUMS     dc  256x'00'
             org TRT_COMMAS+C'0'
             dc  10x'01'
             org

With the valid area tested after the first four commas, you can now
TRT for numerics!, make whatever action you need to and .. job done!

I wanted to point out that conditions on comparisons can be made using
mnemonics, it will be easier to read than using the numeric condition
code, so you have a lot of brach to chiose from, BO, BZ, BNO, BNZ, BG,
BL, BNL, BNG, BE, BNE, so use it and you will have an easier life, so
be sure to learn them!, (Branch on one, branch on zero, branch on
no-ones, branch on no-zeros, branch on less and so on....)

As I stated before I wasn't gonna make the whole program, just
pointing out basic information, I think you can drive on your own from
this point on. One last tip, if the commas are on fixed positions you
may compare directly those places!.

Last but not least, get a POP, that is a basic book even experts read
whenever needed! you won't regret it!

Best wishes, G.C.

Quote:

> Ough!
> S{*filter*}most of this code and start looking at the TRT instruction again
> (if you feel comfortable with that one - it is one of the more challenging
> facitilities in the 370 architecture)

> I believe the POP still has sample code using TRT for parsing.
> What you can do is something like this:

>  LA R1,AREA-1  point just before the area to be parsed
>  SR R2,R2   clear this register, it receives entries from the TRTABLE
>  LA R3,(L'AREA-1)(R1)   set address in register for calculating length
> PARSE1 EQU *
>  LR R4,R3   copy address
>  SR R4,R1   calculate length property for TRT
>  BM COMPLETE  branch if nothing more to parse
>  EX R4,PARSE  get address of next special character in R1
>  BZ COMPLETE  branch if no special character was found
>  B  *(R2) branch to process the special character found
>  B PROCESS4 branch to process character(s) code 4 in TRTABLE
>  B PROCESS8 branch to process character(s) code 8 in TRTABLE
> * one such line for every possible entry in TRTABLE
> PARSE   TRT 1(0,R1),TRTABLE  executed instruction
> PROCESS4 EQU * for instance comma detected
> * do whatever needed when R1 points to the next comma
>  B PARSE1 branch back when finished with code 4
> PROCESS8 EQU * some other character detected
> * do whatever needed when R1 points to some other special character
>  B PARSE1 branch back when finished with code 8

> Your TRTABLE must have 256 zeroes except for the special characters
> you want to detect: X'04' for comma, X'08' for some other and so on.

> Depending upon how you get access to the AREA you may need to
> get its address into R1 and decrement it (BCTR R1,0) and get its
> length into R3, decrement and finally add R1.

> BTW, you just cannot work with IBM assembly language without
> the POP (short for Principles of Operation). There you find a
> thorouogh explanation of every machine instruction available and
> quite a few examples as well. Most of your questions will be
> answered in that book.

> If after this you still want to look again at your own code:
> All your CLI/BNE tests will loop forever unless you happen
> to have only commas in your buffer. You do not increment
> your pointer within each test loop.

> And BC 6 after a TRT instruction will branch unless the
> TRT found nothing but zeroes in the TRTABLE

> regards Sven



> > I know, I'm nuts.  But at 40, I'm trying to become an assembler
> > programmer (hey, what can I say, they posted the job).

> > I just can't seem to get this....

> > When you load an address of a storage area into a register, it's the
> > address of the address, right?  What I'm doing is examining every byte
> > of a record, to see if there are 4 commas (may be other characters
> > inbetween), followed by 5 numbers, which are immediately followed by a
> > comma

> >     ,dizoy,*,s46oihd  ,,12345,lskdfyuasdf,

> > These are variable length records, so what I did was figure the endrec
> > when I do the get for the RPL.  But it's not working.

> > The RPL's area is LIQAREA, a fullword.

> > I am using (Yes, I bet a BCT would be easier, but I want to solve this
> > first):

> >           L    R6,LIQAREA
> > COMMA1    CLI  0(1,R6),X'6B'
> >           BNE  COMMA1
> >           LA   R6,1(R6)
> > COMMA2    CLI  0(1,R6),X'6B'
> >           BNE  COMMA2
> >           LA   R6,1(R6)
> > COMMA3    CLI  0(1,R6),X'6B'
> >           BNE  COMMA3
> >           LA   R6,1(R6)
> > COMMA4    CLI  0(1,R6),X'6B'
> >           BNE  COMMA4
> >           LA   R6,1(R6)

> > Now, using XRAY, this is finally working (dumb mistake, fixed it),
> > but, when I get to the next part, this is where I 'die'.

> >          TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)
> >          BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

> > I am guessing that I am looking at the address in R6, or the beginning
> > of the storage area.  Should I be using LIQAREA to loop through for
> > the commas so I'm pointing in the correct location?

> > I feel REALLY dumb asking this, but I just can't seem to see it.  (And
> > no, I haven't been doing this long)

> > Thanks.



Tue, 08 Mar 2005 05:24:32 GMT  
 Dumb beginner question...

Quote:
>  know, I'm nuts.  But at 40, I'm trying to become an assembler
> programmer (hey, what can I say, they posted the job).

where is this job posted???

eric...



Wed, 09 Mar 2005 13:50:20 GMT  
 Dumb beginner question...
May I suggest that you add a few comments to your code...learn
to do that now and it will seem effortless later on.

Second, you might want to equate the constant C',' to the
label COMMA to make the code even easier to read;
COMMA    EQU    C','
At the least, use
                    CLI    0(R6),C','
instead of
                    CLI    0(R6),X'6B"

Third, a compare immediate doesn't allow for the length to
be specified, as the CLI only compares one byte.  I doubt that
you would have gotten your code to assemble.

Fourth, you have a few infinite loops in your code.  For example,
COMMA1        CLI    0(R6),COMMA
                          BNE    COMMA1
The moment you encounter the 0(R6) as not being a comma you
encounter an infinite loop.  Using the input record you specify, you
should encounter the infinite loop at COMMA2.

To answer your question, assuming that LIQAREA is a fullword
holding the address of your input record, your load instruction
is correct; again, this is assuming that;

LIQAREA    DS    F

and that you've properly loaded it with the address of the
area holding the input record.



Quote:
> I know, I'm nuts.  But at 40, I'm trying to become an assembler
> programmer (hey, what can I say, they posted the job).

> I just can't seem to get this....

> When you load an address of a storage area into a register, it's the
> address of the address, right?  What I'm doing is examining every byte
> of a record, to see if there are 4 commas (may be other characters
> inbetween), followed by 5 numbers, which are immediately followed by a
> comma:

>     ,dizoy,*,s46oihd  ,,12345,lskdfyuasdf,

> These are variable length records, so what I did was figure the endrec
> when I do the get for the RPL.  But it's not working.

> The RPL's area is LIQAREA, a fullword.

> I am using (Yes, I bet a BCT would be easier, but I want to solve this
> first):

>           L    R6,LIQAREA
> COMMA1    CLI  0(1,R6),X'6B'
>           BNE  COMMA1
>           LA   R6,1(R6)
> COMMA2    CLI  0(1,R6),X'6B'
>           BNE  COMMA2
>           LA   R6,1(R6)
> COMMA3    CLI  0(1,R6),X'6B'
>           BNE  COMMA3
>           LA   R6,1(R6)
> COMMA4    CLI  0(1,R6),X'6B'
>           BNE  COMMA4
>           LA   R6,1(R6)

> Now, using XRAY, this is finally working (dumb mistake, fixed it),
> but, when I get to the next part, this is where I 'die'.

>          TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)
>          BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

> I am guessing that I am looking at the address in R6, or the beginning
> of the storage area.  Should I be using LIQAREA to loop through for
> the commas so I'm pointing in the correct location?

> I feel REALLY dumb asking this, but I just can't seem to see it.  (And
> no, I haven't been doing this long)

> Thanks.



Fri, 18 Mar 2005 12:38:13 GMT  
 Dumb beginner question...
Sven,

I noticed in your example the use of
PARSE    EQU    *

I maintained 360 Assembler systems a long time ago (and therefore may be out
of date),
but this was prone to problems when someone inserted something prior to the
EQU
that forced the assembler to generate bytes for instruction alignment.  For
example;

.....
                    B    LABEL_1
STUFF        DC    C'A'
LABEL_1    EQU    *
                    CLC    0(4,R3),SOMETHING
...

In this case, the assembler would have to generate pad bytes (usually as
X'00') to force
LABEL_1 to align on a fullword.  This would result in LABEL_1 equating to
the pad byte(s) and resulting in an S-0C1 when the brance to LABEL_1
occurred.

We always resorted to;
                    B        LABEL_1
STUFF        DC     C'A'
LABEL_1    DS      0H
                    CLC    0(4,R3),SOMETHING
In this case, the DS 0H directs the assembler to to start the label on a
halfword boundary, but not to allocate
any storage.  If already on a halfword boundary then nothing happens;
however, if not then a pad X'00'
is generated prior to the label, forcing the label to start on an integral
halfword boundary.

Again, I may be out of date.  Perhaps some of the more current versions of
the assembler take care of
this.

Thanks,
Don


Quote:
> Ough!
> S{*filter*}most of this code and start looking at the TRT instruction again
> (if you feel comfortable with that one - it is one of the more challenging
> facitilities in the 370 architecture)

> I believe the POP still has sample code using TRT for parsing.
> What you can do is something like this:

>  LA R1,AREA-1  point just before the area to be parsed
>  SR R2,R2   clear this register, it receives entries from the TRTABLE
>  LA R3,(L'AREA-1)(R1)   set address in register for calculating length
> PARSE1 EQU *
>  LR R4,R3   copy address
>  SR R4,R1   calculate length property for TRT
>  BM COMPLETE  branch if nothing more to parse
>  EX R4,PARSE  get address of next special character in R1
>  BZ COMPLETE  branch if no special character was found
>  B  *(R2) branch to process the special character found
>  B PROCESS4 branch to process character(s) code 4 in TRTABLE
>  B PROCESS8 branch to process character(s) code 8 in TRTABLE
> * one such line for every possible entry in TRTABLE
> PARSE   TRT 1(0,R1),TRTABLE  executed instruction
> PROCESS4 EQU * for instance comma detected
> * do whatever needed when R1 points to the next comma
>  B PARSE1 branch back when finished with code 4
> PROCESS8 EQU * some other character detected
> * do whatever needed when R1 points to some other special character
>  B PARSE1 branch back when finished with code 8

> Your TRTABLE must have 256 zeroes except for the special characters
> you want to detect: X'04' for comma, X'08' for some other and so on.

> Depending upon how you get access to the AREA you may need to
> get its address into R1 and decrement it (BCTR R1,0) and get its
> length into R3, decrement and finally add R1.

> BTW, you just cannot work with IBM assembly language without
> the POP (short for Principles of Operation). There you find a
> thorouogh explanation of every machine instruction available and
> quite a few examples as well. Most of your questions will be
> answered in that book.

> If after this you still want to look again at your own code:
> All your CLI/BNE tests will loop forever unless you happen
> to have only commas in your buffer. You do not increment
> your pointer within each test loop.

> And BC 6 after a TRT instruction will branch unless the
> TRT found nothing but zeroes in the TRTABLE

> regards Sven



> > I know, I'm nuts.  But at 40, I'm trying to become an assembler
> > programmer (hey, what can I say, they posted the job).

> > I just can't seem to get this....

> > When you load an address of a storage area into a register, it's the
> > address of the address, right?  What I'm doing is examining every byte
> > of a record, to see if there are 4 commas (may be other characters
> > inbetween), followed by 5 numbers, which are immediately followed by a
> > comma

> >     ,dizoy,*,s46oihd  ,,12345,lskdfyuasdf,

> > These are variable length records, so what I did was figure the endrec
> > when I do the get for the RPL.  But it's not working.

> > The RPL's area is LIQAREA, a fullword.

> > I am using (Yes, I bet a BCT would be easier, but I want to solve this
> > first):

> >           L    R6,LIQAREA
> > COMMA1    CLI  0(1,R6),X'6B'
> >           BNE  COMMA1
> >           LA   R6,1(R6)
> > COMMA2    CLI  0(1,R6),X'6B'
> >           BNE  COMMA2
> >           LA   R6,1(R6)
> > COMMA3    CLI  0(1,R6),X'6B'
> >           BNE  COMMA3
> >           LA   R6,1(R6)
> > COMMA4    CLI  0(1,R6),X'6B'
> >           BNE  COMMA4
> >           LA   R6,1(R6)

> > Now, using XRAY, this is finally working (dumb mistake, fixed it),
> > but, when I get to the next part, this is where I 'die'.

> >          TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)
> >          BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

> > I am guessing that I am looking at the address in R6, or the beginning
> > of the storage area.  Should I be using LIQAREA to loop through for
> > the commas so I'm pointing in the correct location?

> > I feel REALLY dumb asking this, but I just can't seem to see it.  (And
> > no, I haven't been doing this long)

> > Thanks.



Fri, 18 Mar 2005 12:59:16 GMT  
 Dumb beginner question...
No, you are not out of date, and I always used the DS 0H (or DS 0Y)
construction for the first instruction address reference following any
storage definition statement(s). But between statements I frequently
preferred
 the equ * construction because I felt that it stands out a bit better.

Generally I architected my modules like this:

Module CSECT
 B ENTRY
 label and eyecatchers
 savearea
 other data areas (DS and DC)
ENTRY SAVE (14,12) .....
 local code with USING SAVEAREA,13
.....
 END

and had little need to worry about alignment

regards Sven


Quote:
> Sven,

> I noticed in your example the use of
> PARSE    EQU    *

> I maintained 360 Assembler systems a long time ago (and therefore may be
out
> of date),
> but this was prone to problems when someone inserted something prior to
the
> EQU
> that forced the assembler to generate bytes for instruction alignment.
For
> example;

> .....
>                     B    LABEL_1
> STUFF        DC    C'A'
> LABEL_1    EQU    *
>                     CLC    0(4,R3),SOMETHING
> ...

> In this case, the assembler would have to generate pad bytes (usually as
> X'00') to force
> LABEL_1 to align on a fullword.  This would result in LABEL_1 equating to
> the pad byte(s) and resulting in an S-0C1 when the brance to LABEL_1
> occurred.

> We always resorted to;
>                     B        LABEL_1
> STUFF        DC     C'A'
> LABEL_1    DS      0H
>                     CLC    0(4,R3),SOMETHING
> In this case, the DS 0H directs the assembler to to start the label on a
> halfword boundary, but not to allocate
> any storage.  If already on a halfword boundary then nothing happens;
> however, if not then a pad X'00'
> is generated prior to the label, forcing the label to start on an integral
> halfword boundary.

> Again, I may be out of date.  Perhaps some of the more current versions of
> the assembler take care of
> this.

> Thanks,
> Don



> > Ough!
> > S{*filter*}most of this code and start looking at the TRT instruction again
> > (if you feel comfortable with that one - it is one of the more
challenging
> > facitilities in the 370 architecture)

> > I believe the POP still has sample code using TRT for parsing.
> > What you can do is something like this:

> >  LA R1,AREA-1  point just before the area to be parsed
> >  SR R2,R2   clear this register, it receives entries from the TRTABLE
> >  LA R3,(L'AREA-1)(R1)   set address in register for calculating length
> > PARSE1 EQU *
> >  LR R4,R3   copy address
> >  SR R4,R1   calculate length property for TRT
> >  BM COMPLETE  branch if nothing more to parse
> >  EX R4,PARSE  get address of next special character in R1
> >  BZ COMPLETE  branch if no special character was found
> >  B  *(R2) branch to process the special character found
> >  B PROCESS4 branch to process character(s) code 4 in TRTABLE
> >  B PROCESS8 branch to process character(s) code 8 in TRTABLE
> > * one such line for every possible entry in TRTABLE
> > PARSE   TRT 1(0,R1),TRTABLE  executed instruction
> > PROCESS4 EQU * for instance comma detected
> > * do whatever needed when R1 points to the next comma
> >  B PARSE1 branch back when finished with code 4
> > PROCESS8 EQU * some other character detected
> > * do whatever needed when R1 points to some other special character
> >  B PARSE1 branch back when finished with code 8

> > Your TRTABLE must have 256 zeroes except for the special characters
> > you want to detect: X'04' for comma, X'08' for some other and so on.

> > Depending upon how you get access to the AREA you may need to
> > get its address into R1 and decrement it (BCTR R1,0) and get its
> > length into R3, decrement and finally add R1.

> > BTW, you just cannot work with IBM assembly language without
> > the POP (short for Principles of Operation). There you find a
> > thorouogh explanation of every machine instruction available and
> > quite a few examples as well. Most of your questions will be
> > answered in that book.

> > If after this you still want to look again at your own code:
> > All your CLI/BNE tests will loop forever unless you happen
> > to have only commas in your buffer. You do not increment
> > your pointer within each test loop.

> > And BC 6 after a TRT instruction will branch unless the
> > TRT found nothing but zeroes in the TRTABLE

> > regards Sven



> > > I know, I'm nuts.  But at 40, I'm trying to become an assembler
> > > programmer (hey, what can I say, they posted the job).

> > > I just can't seem to get this....

> > > When you load an address of a storage area into a register, it's the
> > > address of the address, right?  What I'm doing is examining every byte
> > > of a record, to see if there are 4 commas (may be other characters
> > > inbetween), followed by 5 numbers, which are immediately followed by a
> > > comma

> > >     ,dizoy,*,s46oihd  ,,12345,lskdfyuasdf,

> > > These are variable length records, so what I did was figure the endrec
> > > when I do the get for the RPL.  But it's not working.

> > > The RPL's area is LIQAREA, a fullword.

> > > I am using (Yes, I bet a BCT would be easier, but I want to solve this
> > > first):

> > >           L    R6,LIQAREA
> > > COMMA1    CLI  0(1,R6),X'6B'
> > >           BNE  COMMA1
> > >           LA   R6,1(R6)
> > > COMMA2    CLI  0(1,R6),X'6B'
> > >           BNE  COMMA2
> > >           LA   R6,1(R6)
> > > COMMA3    CLI  0(1,R6),X'6B'
> > >           BNE  COMMA3
> > >           LA   R6,1(R6)
> > > COMMA4    CLI  0(1,R6),X'6B'
> > >           BNE  COMMA4
> > >           LA   R6,1(R6)

> > > Now, using XRAY, this is finally working (dumb mistake, fixed it),
> > > but, when I get to the next part, this is where I 'die'.

> > >          TRT   0(5,R6),TRT_TABLE  (CHECKING FOR NUMERICS)
> > >          BC    6,PRINT_ERROR    (IT IS ALWAYS PRINTING AS AN ERROR)

> > > I am guessing that I am looking at the address in R6, or the beginning
> > > of the storage area.  Should I be using LIQAREA to loop through for
> > > the commas so I'm pointing in the correct location?

> > > I feel REALLY dumb asking this, but I just can't seem to see it.  (And
> > > no, I haven't been doing this long)

> > > Thanks.



Fri, 18 Mar 2005 15:15:31 GMT  
 Dumb beginner question...
I don't know if you would call it a standard, but I learned to use DS 0H
but have since changed to use DS 0S.  The 0S aligns to the "instruction
alignment" so if this ever changes (not real likely but possible, I
guess) you would be covered.  The S-type is for the base/displacement
configuration and the alignment is to where that would fall in an
instruction......ie. halfword alignment!!

Quote:

> No, you are not out of date, and I always used the DS 0H (or DS 0Y)
> construction for the first instruction address reference following any
> storage definition statement(s). But between statements I frequently
> preferred
>  the equ * construction because I felt that it stands out a bit better.

> Generally I architected my modules like this:

<snip>

--
Chris Pomasl
Starband Skyblaster, 012/65
Suse Linux 8.0
Senior Software Engineer - DB2 products
Computer Associates, inc

Always remember, you are unique.....just like everyone else!!
To email me, remove the spam stuff from my eddress



Fri, 18 Mar 2005 23:53:25 GMT  
 Dumb beginner question...

Quote:

>I don't know if you would call it a standard, but I learned to use DS 0H
>but have since changed to use DS 0S.  The 0S aligns to the "instruction
>alignment" so if this ever changes (not real likely but possible, I
>guess) you would be covered.  The S-type is for the base/displacement
>configuration and the alignment is to where that would fall in an
>instruction......ie. halfword alignment!!


>> No, you are not out of date, and I always used the DS 0H (or DS 0Y)
>> construction for the first instruction address reference following any
>> storage definition statement(s). But between statements I frequently
>> preferred
>>  the equ * construction because I felt that it stands out a bit better.

>> Generally I architected my modules like this:

><snip>

>--

Why bother with any of these:

BLAP   EQU   *
            LA      .......

BLAP   DS     0H
            LA     ........

BLAP   DC     0H'0'
            LA     ........

BLAP    DS    0Y
            LA     .....

BLAP    DS    0S
            LA    ......

When all you need is this:

BLAP    LA    ......

???????



Sun, 20 Mar 2005 08:39:11 GMT  
 Dumb beginner question...


Quote:

> Why bother with any of these:

> BLAP   EQU   *
>             LA      .......

> BLAP   DS     0H
>             LA     ........

> BLAP   DC     0H'0'
>             LA     ........

> BLAP    DS    0Y
>             LA     .....

> BLAP    DS    0S
>             LA    ......

> When all you need is this:

> BLAP    LA    ......

Because I have a page eject and a dozen lines of subsection documentation
that need to go between the BLAP and the LA.

John Homes



Sun, 20 Mar 2005 09:31:25 GMT  
 Dumb beginner question...


Quote:




> > Why bother with any of these:

> > BLAP   EQU   *
> >             LA      .......

> > BLAP   DS     0H
> >             LA     ........

> > BLAP   DC     0H'0'
> >             LA     ........

> > BLAP    DS    0Y
> >             LA     .....

> > BLAP    DS    0S
> >             LA    ......

> > When all you need is this:

> > BLAP    LA    ......

> Because I have a page eject and a dozen lines of subsection documentation
> that need to go between the BLAP and the LA.

> John Homes

And in preparation to possible future program modifications that require
other statements to be inserted first after label BLAP

It is part of something we call "maintainability" of the code.

Sven



Sun, 20 Mar 2005 15:48:31 GMT  
 Dumb beginner question...

Quote:
> And in preparation to possible future program modifications that require
> other statements to be inserted first after label BLAP

> It is part of something we call "maintainability" of the code.

Are you still maintaining your code on a keypunch? AFAIK, that is the
biggest reason for the tradition of placing labels on their own statement.


Sun, 20 Mar 2005 22:00:02 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Dumb beginner question; what is IDLE?

2. Dumb newbie asks dumber question

3. GPF goes away when use debugger...or Dumb and Dumber

4. button question (not a beginner question?)

5. Dumb question re date/time picker

6. Automation - dumb question

7. Real Dumb Question on APL Domino

8. Dumb question about binary representaions in J

9. more dumb newbie questions

10. Benchmark Workshop tool - dumb (?) question

11. dumb question

12. very newbie dumb question

 

 
Powered by phpBB® Forum Software