Cobol - How would you do this?

Author

How would you do this?

William M. Klein

2007-03-11, 6:55 pm

to: comp.lang.cobol *and* IBM-MAIN

IBM has (relatively) recently created an LE callable service, CEE3INF, that
returns a "32-bit map" with information about what environment a program is
running in. See:

http://publibz.boulder.ibm.com/cgi-...EEA3170/2.2.5.9

Now, my question is how various "experienced" COBOL programmers would handle
such information (either in an IBM mainframe environment OR in other COBOL
environments for those who see this note and don't work in IBM mainframe
environments - but do get "bit maps")

1) Call a non-COBOL program to decode this map (e.g.. Assembler, C, PL/I or any
other language that can easily handle "bits")

2) Do a "division" loop to figure out which bits are turned on?

3) Use 88-levels with hex literals to check for which bits were turned on?

4) Use the LE (or comparable) "bit manipulation" routines?

5) Not use CEE3INF from COBOL?

6) Other?

***

Although I wouldn't LIKE it, I can imagine doing this in any of these ways.
Obviously, when/if a COBOL compiler supports the '02 Standard Bit/Boolean
features, this becomes "trivial". However, as few (if any) compilers do this
yet, I was wondering how programmers would handle this requirement.

--
Bill Klein
wmklein <at> ix.netcom.com

Rick Smith

2007-03-11, 6:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:rrDIh.242220$k82.140284@fe07.news.easynews.com...
> to: comp.lang.cobol *and* IBM-MAIN
>
> IBM has (relatively) recently created an LE callable service, CEE3INF,
that
> returns a "32-bit map" with information about what environment a program
is
> running in. See:
>
>
http://publibz.boulder.ibm.com/cgi-...EEA3170/2.2.5.9
>
> Now, my question is how various "experienced" COBOL programmers would
handle
> such information (either in an IBM mainframe environment OR in other COBOL
> environments for those who see this note and don't work in IBM mainframe
> environments - but do get "bit maps")
>
> 1) Call a non-COBOL program to decode this map (e.g.. Assembler, C, PL/I
or any
> other language that can easily handle "bits")
>
> 2) Do a "division" loop to figure out which bits are turned on?
>
> 3) Use 88-levels with hex literals to check for which bits were turned on?
>
> 4) Use the LE (or comparable) "bit manipulation" routines?
>
> 5) Not use CEE3INF from COBOL?
>
> 6) Other?
>
> ***
>
> Although I wouldn't LIKE it, I can imagine doing this in any of these
ways.
> Obviously, when/if a COBOL compiler supports the '02 Standard Bit/Boolean
> features, this becomes "trivial". However, as few (if any) compilers do
this
> yet, I was wondering how programmers would handle this requirement.

There are a lot of "reserved" bits in the four full-words.
While some of these may become assigned, it seems
unlikely that any would be moved. As new bits become
assigned, a routine that processes all bits, such as a
"division loop" would, I believe, be more sensitive to
maintenance than one that extracts the bit fields directly.
Also one need not extract more than is desired.

Extracting these bit fields directly seems a rather
straight-forward process with intrinsic functions. The
exponents below are 31 minus the low-order bit number
of the field.

-----
compute c-bit = function mod
(function integer (member-id / (2 ** 28)) 2)
compute cobol-bit = function mod
(function integer (member-id / (2 ** 26)) 2)
compute amode = function mod
(function integer (env-info / (2 ** 17)) 4)
compute product-number = function integer
(gpid / (2 ** 24))
compute version = function mod
(function integer (gpid / (2 ** 16)) 256)
compute releasse = function mod
(function integer (gpid / (2 ** 8)) 256)
compute modification = function mod
(gpid 256)
-----

William M. Klein

2007-03-11, 6:55 pm

Richard,
Are you assuming that "Moded fields" are USAGE BINARY-CHAR - or a "BINARY"
(with non-ANSI "notrunc" behavior). Otherwise, I don't know how you are
processing them. This is part of my problem in "solving" this problem.
Standard COBOL (pre- USAGE BINARY-CHAR) has no way to define a numeric field as
"binary" without truncation.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12v6pek1atd1a64@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:rrDIh.242220$k82.140284@fe07.news.easynews.com...
> that
> is
> http://publibz.boulder.ibm.com/cgi-...EEA3170/2.2.5.9
> handle
> or any
> ways.
> this
>
> There are a lot of "reserved" bits in the four full-words.
> While some of these may become assigned, it seems
> unlikely that any would be moved. As new bits become
> assigned, a routine that processes all bits, such as a
> "division loop" would, I believe, be more sensitive to
> maintenance than one that extracts the bit fields directly.
> Also one need not extract more than is desired.
>
> Extracting these bit fields directly seems a rather
> straight-forward process with intrinsic functions. The
> exponents below are 31 minus the low-order bit number
> of the field.
>
> -----
> compute c-bit = function mod
> (function integer (member-id / (2 ** 28)) 2)
> compute cobol-bit = function mod
> (function integer (member-id / (2 ** 26)) 2)
> compute amode = function mod
> (function integer (env-info / (2 ** 17)) 4)
> compute product-number = function integer
> (gpid / (2 ** 24))
> compute version = function mod
> (function integer (gpid / (2 ** 16)) 256)
> compute releasse = function mod
> (function integer (gpid / (2 ** 8)) 256)
> compute modification = function mod
> (gpid 256)
> -----
>
>
>

Louis Krupp

2007-03-11, 6:55 pm

Louis Krupp

2007-03-11, 6:55 pm

Louis Krupp wrote:
> William M. Klein wrote:
>
> I'd consider writing a C routine that would explode the bitmaps into
> tables of 32 integers (PIC 9 COMP or PIC 9 DISPLAY or whatever works).
> You'd have to make sure you knew how the table would be laid out in
> memory, so you might consider sacrificing memory and speed for
> portability. The 32-bit word with four 8-bit fields could be split into
> four PIC 99 fields.

Oops. Make that PIC 9(3).

Louis

Rick Smith

2007-03-11, 6:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:MsLIh.6139$pj4.2291@fe09.news.easynews.com...
> Richard,
> Are you assuming that "Moded fields" are USAGE BINARY-CHAR - or a
"BINARY"
> (with non-ANSI "notrunc" behavior). Otherwise, I don't know how you are
> processing them. This is part of my problem in "solving" this problem.
> Standard COBOL (pre- USAGE BINARY-CHAR) has no way to define a numeric
field as
> "binary" without truncation.

PIC 9(9) BINARY

The call to CEE3INF, as I understand it, will return the
values untruncated. Since truncation occurs when the
COBOL program stores the result of a calculation, I
don't see truncation, from the COMPUTE statements,
as a problem.

The worrisome case appears to be getting bit 0 of a field,
such as, the CICS bit from sys/subsys; since this would
involve division by +2147483648 (2 ** 31).

compute cics-bit = function mod
(function integer (sys-subsys / (2 ** 31)) 2)

This statement correctly returns either +1 or +0 with
ANSI truncation (the default) in effect, on Micro Focus
COBOL 3.2.24.

-----
$set ibmcomp vsc2 arithmetic"vsc2"
identification division.
program-id. test3inf.
working-storage section.
01 sys-subsys pic 9(9) binary value 0.
01 cics-bit pic s9(4) binary value +0.
procedure division.
begin.
move x"80000000" to sys-subsys (1:4)
compute cics-bit = function mod
(function integer (sys-subsys / (2 ** 31)) 2)
if cics-bit = +1
display "CICS bit is on"
end-if
goback.
-----

> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:12v6pek1atd1a64@corp.supernews.com...
program[color=darkred]
http://publibz.boulder.ibm.com/cgi-...EEA3170/2.2.5.9[color=darkred]
COBOL[color=darkred]
mainframe[color=darkred]
PL/I[color=darkred]
on?[color=darkred]
Bit/Boolean[color=darkred]
do[color=darkred]
>
>

William M. Klein

2007-03-11, 6:55 pm

You may be right (but I am still not certain) for IBM mainframes. According to:
http://publibz.boulder.ibm.com/cgi-...igy3pg32/2.4.54

"TRUNC(STD) applies only to USAGE BINARY receiving fields in MOVE statements and
arithmetic expressions."

but it then goes on to say,
"When TRUNC(STD) is in effect, the final result of an arithmetic expression,
...., is truncated"

So I am not certain where in your compute statement the truncation would occur
(if at all), i.e. for the "arithmetic expression" (evaluation) or in the FINAL
move to the receiving field. I don't (easily) have an Enterprise COBOL system
to test with, so I can't tell for sure. (I just "in general" HATE to rely on
any stage of USAGE BINARY items where the data is larger than the PICTURE).

P.S. If you haven't ever seen exactly what IBM does (and it IS different from
Micro Focus), you might want to look at the examples at:

http://publibz.boulder.ibm.com/cgi-...y3pg32/2.4.54.1

and

http://publibz.boulder.ibm.com/cgi-...y3pg32/2.4.54.2

some of the results are truly "mind boggling"
--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12v7j5rd1ec59cd@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:MsLIh.6139$pj4.2291@fe09.news.easynews.com...
> "BINARY"
> field as
>
> PIC 9(9) BINARY
>
> The call to CEE3INF, as I understand it, will return the
> values untruncated. Since truncation occurs when the
> COBOL program stores the result of a calculation, I
> don't see truncation, from the COMPUTE statements,
> as a problem.
>
> The worrisome case appears to be getting bit 0 of a field,
> such as, the CICS bit from sys/subsys; since this would
> involve division by +2147483648 (2 ** 31).
>
> compute cics-bit = function mod
> (function integer (sys-subsys / (2 ** 31)) 2)
>
> This statement correctly returns either +1 or +0 with
> ANSI truncation (the default) in effect, on Micro Focus
> COBOL 3.2.24.
>
> -----
> $set ibmcomp vsc2 arithmetic"vsc2"
> identification division.
> program-id. test3inf.
> working-storage section.
> 01 sys-subsys pic 9(9) binary value 0.
> 01 cics-bit pic s9(4) binary value +0.
> procedure division.
> begin.
> move x"80000000" to sys-subsys (1:4)
> compute cics-bit = function mod
> (function integer (sys-subsys / (2 ** 31)) 2)
> if cics-bit = +1
> display "CICS bit is on"
> end-if
> goback.
> -----
>
> program
> http://publibz.boulder.ibm.com/cgi-...EEA3170/2.2.5.9
> COBOL
> mainframe
> PL/I
> on?
> Bit/Boolean
> do
>
>

Michael Mattias

2007-03-11, 6:55 pm

01 SYS-SUSBSYS PIC S9(09) USAGE BINARY

CALL 'CEE3INF' USING BY REFERENCE SYS-SUBYS .....

DIVIDE SYS-SUBSYS BY 2 GIVING X REMAINDER BIT-0

(You can just 'ladder' DIVIDE by 2 and keeping remainders; the remainders
will be the bits)

MCM

Pete Dashwood

2007-03-11, 9:55 pm

end so I checked your link above
and then downloaded the z/OS COBOL manual to see what you can actually DO...
I note with regret that PIC 1 (Binary) is missing... :-) (Now, THAT's
something that would be much more useful in the COBOL standard than embedded
XML...)

Anyway, having faced this problem in the Client/Server environment some
years back I am satisifed that the problem is NOT about what bits mean what,
it is about being able to reference bits from COBOL at all.

You mentioned the traditional approaches and I've given my opinions below.

>
> Now, my question is how various "experienced" COBOL programmers would
> handle such information (either in an IBM mainframe environment OR in
> other COBOL environments for those who see this note and don't work in IBM
> mainframe environments - but do get "bit maps")
>
> 1) Call a non-COBOL program to decode this map (e.g.. Assembler, C, PL/I
> or any other language that can easily handle "bits")

No. I looked at doing it in Java and then invoking the Java class from z/OS
but it would have taken more time than I was prepared to spend on it to
fully investigate and code the solution.(If I was working in a mainframe
environment, I'd simply invest the time and do it this way. Java is fully
transportable and so should COBOL be, if that is important to you. (It is a
consideration for me, but not a show stopper...)

This approach has the advantages that it is OO, encapsulated, and
transportable.

>
> 2) Do a "division" loop to figure out which bits are turned on?

Yeah, brute force. Effective but inelegant.
>
> 3) Use 88-levels with hex literals to check for which bits were turned on?

Imaginative, but a bit ugly.
>
> 4) Use the LE (or comparable) "bit manipulation" routines?

Certainly that was the approach I opted for in the MicroFocus environment
many years ago. They provided bit conversion routines that were callable
from COBOL, but of course, as soon as you use them, any hope of platform
transportability is gone...

>
> 5) Not use CEE3INF from COBOL?
>

Seems a bit drastic :-)

> 6) Other?
>

Given that the real problem is converting bits to bytes so COBOL can address
them, it seemed to me that the Java option is the one I would go for.
However, I then read Rick's post and it is simple and elegant. I understand
you have some reservations about it working with mainframe TRUNC options but
I'd simply try it out as quickly as possible.

Given that it worked, I'd go with that. The intrinsic MOD function it uses
is available on every platform I've seen that supports intrinsic
functions...

I reckon this is imagnative simple and direct.

Definitely gets my vote.

Pete.

Pete Dashwood

2007-03-11, 9:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12v6pek1atd1a64@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:rrDIh.242220$k82.140284@fe07.news.easynews.com...
> that
> is
> http://publibz.boulder.ibm.com/cgi-...EEA3170/2.2.5.9
> handle
> or any
> ways.
> this
>
> There are a lot of "reserved" bits in the four full-words.
> While some of these may become assigned, it seems
> unlikely that any would be moved. As new bits become
> assigned, a routine that processes all bits, such as a
> "division loop" would, I believe, be more sensitive to
> maintenance than one that extracts the bit fields directly.
> Also one need not extract more than is desired.
>
> Extracting these bit fields directly seems a rather
> straight-forward process with intrinsic functions. The
> exponents below are 31 minus the low-order bit number
> of the field.
>
> -----
> compute c-bit = function mod
> (function integer (member-id / (2 ** 28)) 2)
> compute cobol-bit = function mod
> (function integer (member-id / (2 ** 26)) 2)
> compute amode = function mod
> (function integer (env-info / (2 ** 17)) 4)
> compute product-number = function integer
> (gpid / (2 ** 24))
> compute version = function mod
> (function integer (gpid / (2 ** 16)) 256)
> compute releasse = function mod
> (function integer (gpid / (2 ** 8)) 256)
> compute modification = function mod
> (gpid 256)
> -----
>
>
>
Excellent! Great stuff, Rick.

Pete.

2007-03-11, 9:55 pm

William M. Klein wrote:
> to: comp.lang.cobol *and* IBM-MAIN
>
> IBM has (relatively) recently created an LE callable service, CEE3INF, that
> returns a "32-bit map" with information about what environment a program is
> running in. See:
>
> http://publibz.boulder.ibm.com/cgi-...EEA3170/2.2.5.9
>
> Now, my question is how various "experienced" COBOL programmers would handle
> such information (either in an IBM mainframe environment OR in other COBOL
> environments for those who see this note and don't work in IBM mainframe
> environments - but do get "bit maps")
>
> 1) Call a non-COBOL program to decode this map (e.g.. Assembler, C, PL/I or any
> other language that can easily handle "bits")
>
> 2) Do a "division" loop to figure out which bits are turned on?
>
> 3) Use 88-levels with hex literals to check for which bits were turned on?
>
> 4) Use the LE (or comparable) "bit manipulation" routines?
>
> 5) Not use CEE3INF from COBOL?
>
> 6) Other?
>
> ***
>
> Although I wouldn't LIKE it, I can imagine doing this in any of these ways.
> Obviously, when/if a COBOL compiler supports the '02 Standard Bit/Boolean
> features, this becomes "trivial". However, as few (if any) compilers do this
> yet, I was wondering how programmers would handle this requirement.
>
Bill,
Since you are already using LE Callable Services, why not use:

> CEESITST: Bit test
> * CEESITST selectively tests a bit in its parm1 input to determine if
> the bit is on.
>
> Syntax
> CEESITST (parm1 ,parm2 ,fc ,result )
> Where:
> parm1 (input)
> The first input to the Bit Test routine. The input
> can be any 32-bit integer.
> parm2 (input)
> The second input to the Bit Test routine. The input
> is a 32-bit integer in the range 0 =< parm2 =< 31.
> fc (output)
> A 12-byte feedback code, optional in some languages,
> that indicates the result of this service.
>
> The following symbolic conditions can result from this service:
> result (output)
> The result of the Bit Test routine. The output is a
> 32-bit integer with value:
> 1, if bit number parm2 in parm1 is 1
> 0, if bit number parm2 in parm1 is 0
> Bits are counted from the right.
Ref: Language Environment Programming Reference
Chapter 5: Bit manipulation routines
SA22-7562-08 [z/OS V1.8]
Carl

Pete Dashwood

2007-03-12, 3:55 am

"CG" <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote in message
news:9fdc5$45f4ba41$4275fbdb$21645@FUSE.NET...
> William M. Klein wrote:
> Bill,
> Since you are already using LE Callable Services, why not use:
>
> Ref: Language Environment Programming Reference
> Chapter 5: Bit manipulation routines
> SA22-7562-08 [z/OS V1.8]
> Carl

That looks fine Carl and was the approach I adopted about 9 years ago when I
first had this problem. (Use callable bit manipulation routines provided in
the environment.)

I have a few reservations (although I agree it is a perfectly valid solution
in the stated environment):

1. If you are looking for a general solution (for cases where you AREN'T
calling CEE3INF for example... you just need to "interpret" a bit
string...) this becomes less attractive. Calling either of these routines
ties you to a specific environment.

2. Rick's solution will work in almost any environment and is very few lines
of code without having to worry about CALL and parameters. It is solid COBOL
and should work in any COBOL environment where they support intrinsic
functions.

3. If you are going to call anything, it would be better to call a
non-environment specific module or object. Java presents itself here as a
prime candidate.

4. I was surprised the routine above returns a binary number that is 1 or 0;
in the IBM environment I would have expected a byte, which is much more
amenable to CLC and CLI, instructions without requiring any conversion. I
suspect that collating sequences other than just plain EBCDIC are being
considered here...

Left to my own devices, I would've opted for the Java/COBOL mix and made it
an OO Class, invokable from COBOL. I like Rick's solution much better.

Pete.

PS I don't hink it is fair for this thread to refer to this process as "bit
mapping". This term has a specific meaning and connotation in other
environments. What is happening here is interpretation (deriving meaning
from), or analysis of, a bit string.

2007-03-12, 3:55 am

Pete Dashwood wrote:
> "CG" <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote in message
> news:9fdc5$45f4ba41$4275fbdb$21645@FUSE.NET...
>
> That looks fine Carl and was the approach I adopted about 9 years ago when I
> first had this problem. (Use callable bit manipulation routines provided in
> the environment.)
>
> I have a few reservations (although I agree it is a perfectly valid solution
> in the stated environment):
>
> 1. If you are looking for a general solution (for cases where you AREN'T
> calling CEE3INF for example... you just need to "interpret" a bit
> string...) this becomes less attractive. Calling either of these routines
> ties you to a specific environment.
>
> 2. Rick's solution will work in almost any environment and is very few lines
> of code without having to worry about CALL and parameters. It is solid COBOL
> and should work in any COBOL environment where they support intrinsic
> functions.
>
> 3. If you are going to call anything, it would be better to call a
> non-environment specific module or object. Java presents itself here as a
> prime candidate.
>
> 4. I was surprised the routine above returns a binary number that is 1 or 0;
> in the IBM environment I would have expected a byte, which is much more
> amenable to CLC and CLI, instructions without requiring any conversion. I
> suspect that collating sequences other than just plain EBCDIC are being
> considered here...
>
> Left to my own devices, I would've opted for the Java/COBOL mix and made it
> an OO Class, invokable from COBOL. I like Rick's solution much better.
>
> Pete.
>
> PS I don't hink it is fair for this thread to refer to this process as "bit
> mapping". This term has a specific meaning and connotation in other
> environments. What is happening here is interpretation (deriving meaning
> from), or analysis of, a bit string.

First, an obvious point: The reason this approach is applicable is
because it means that the programmer/user does not have to do anything
special other than use the service provided... It's part of the system.

As you would probably expect, please consider that Bill's question was
very specific to his objection to the implementation of CEE3INF. This
service is not only explicit to LE, but the '3' in the name makes it
even more specific to the "S/390" [read mainframe, OS/390, MVS, z/OS, et
al] environment. Therefore, there is no situation where someone using
CEE3INF would not also have clear access to the Bit Manipulation
services that I suggested. [There are, BTW, a set of four services for
setting, clearing, shifting and testing bits.]

I don't find the binary returned value objectionable because it is
highly unlikely that you would ever actually translate the value to
anything, much less a character. You test it with a relatively fast
compare and get on with the logic.

Certainly, if you want to broaden the subject to include all situations
of bit mangling, then native language [IMHO] is the only way to go.
And, if you are in control of the application design and know you are
lacking such language, change the design to match the features you do have.

Finally, your objection to 'bit mapping' is noted, but a FIND in the
message text returned your use of the word 'mapping' as the only instance.

Carl

Rick Smith

2007-03-12, 3:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:55jmglF25132bU1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:12v6pek1atd1a64@corp.supernews.com...
[snip]
> Excellent! Great stuff, Rick.

Thank you for your kind words, here and elsewhere.

This is little more than the implementation, in COBOL,
of a few assembler instructions. The use of powers of 2
translates to logical "shift" and "and". For IBM, the inline
instruction sequence, for those with both functions (and
this could be used for all), is:
L
SRL
N
STH

Any who are truly uncomfortable with using COBOL
to extract bit fields could write an equivalent assembler
routine and call it.

William M. Klein

2007-03-12, 7:55 am

Of course the "odd" thing is how you need to create the parms for a call to
CEESITST. The simple fact is that COBOL does *NOT* have (before the '02
Standard and IBM hasn't implemented USAGE BINARY-CHAR or any other BINARY-xxx
usage) a way to specify a

32-bit integer

The best (non-Standard) way to do this in Enterprise COBOL is to say
05 32Int Pic S9(9) Comp-5.

but even THEN it is hard to test the "high-level" bit. In reality, you would
PROBABLY end up passing
Pic X(4)
fields to CEESITST (in COBOL) and use hex-literals to set bits that you want to
test, The following is how I *guess* that CEESITST would actually be used in
COBOL (you should note that there is NO "usage" example any where in the
existing LE manuals).

05 Parm1 Pic S9(9) Comp-5
05 Parm2 Pic X(4)
05 Reslt Pic S9(9) Comp-5
....
Move to-be-tested to Parm1
Move 17 to Parm1
Call "CEESITST" Using Parm1 Parm2 FC Reslt
If Reslt = 1
Display "bit 17 - in a way that COBOL never counts - is ON
Else
Display "bit 17 is off"
End-If

****

As there is NO example of how to use this callable service, I am not POSITIVE
this is correct, but I think it is.

--
Bill Klein
wmklein <at> ix.netcom.com
"CG" <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote in message
news:55953$45f4e0a0$4275fbdb$18078@FUSE.NET...
> Pete Dashwood wrote:
>
> First, an obvious point: The reason this approach is applicable is because it
> means that the programmer/user does not have to do anything special other than
> use the service provided... It's part of the system.
>
> As you would probably expect, please consider that Bill's question was very
> specific to his objection to the implementation of CEE3INF. This service is
> not only explicit to LE, but the '3' in the name makes it even more specific
> to the "S/390" [read mainframe, OS/390, MVS, z/OS, et al] environment.
> Therefore, there is no situation where someone using CEE3INF would not also
> have clear access to the Bit Manipulation services that I suggested. [There
> are, BTW, a set of four services for setting, clearing, shifting and testing
> bits.]
>
> I don't find the binary returned value objectionable because it is highly
> unlikely that you would ever actually translate the value to anything, much
> less a character. You test it with a relatively fast compare and get on with
> the logic.
>
> Certainly, if you want to broaden the subject to include all situations of bit
> mangling, then native language [IMHO] is the only way to go. And, if you are
> in control of the application design and know you are lacking such language,
> change the design to match the features you do have.
>
> Finally, your objection to 'bit mapping' is noted, but a FIND in the message
> text returned your use of the word 'mapping' as the only instance.
>
> Carl

HeyBub

2007-03-12, 6:55 pm

William M. Klein wrote:
> Now, my question is how various "experienced" COBOL programmers would
> handle such information (either in an IBM mainframe environment OR in
> other COBOL environments for those who see this note and don't work
> in IBM mainframe environments - but do get "bit maps")

By reducing the problem to one that's already been solved?

From the ETK collection of nifty subroutines:

-------
Summary: Provides bit manipulations of up to 32 bits. Can get, set, clear,
test, and pack bits.

How to use: Instead of non-portable redefinitions to access bits packed in
numeric variables, use BITPK's get operation to convert a number into a
string of 32 characters each with values "0" or "1". You can then easily
test or otherwise manipulate these character values. The pack operation
packs the character values back into a number.

Limitations: At most 32 bits can be handled at a time.

To call BITPK, define BITPK-CONTROL as follows:

01 BITPK-CONTROL.
02 BITPK-TASK-ID PIC X(4) .
02 BITPK-OPERATION PIC X(1) .
02 BITPK-FEEDBACK PIC X(1) .
02 BITPK-NUMBER PIC 9(10).
02 BITPK-BITS.
03 BITPK-BIT PIC X(1) OCCURS 32 TIMES.
Define CALL-BITPK as follows:
CALL-BITPK.
CALL "BITPK"
USING BITPK-CONTROL

Rick Smith

2007-03-12, 9:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12vam7smnj5dmd8@news.supernews.com...
> William M. Klein wrote:
>
> By reducing the problem to one that's already been solved?

I thought about recommending ETKPAK, as well;
but rejected it as "overkill" and my feeling that it
did not solve the problem of obtaining the values
of multi-bit fields.

> From the ETK collection of nifty subroutines:
[snip]
> 02 BITPK-NUMBER PIC 9(10).

Be aware that this field is has usage COMP in the
linkage section of the called program.

HeyBub

2007-03-12, 9:55 pm

Rick Smith wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:12vam7smnj5dmd8@news.supernews.com...
>
> I thought about recommending ETKPAK, as well;
> but rejected it as "overkill" and my feeling that it
> did not solve the problem of obtaining the values
> of multi-bit fields.
>

Well not directly, it doesn't. It takes a 32-bit value and maps it to 32
one-byte fields which can be individually tested. The rest is left as an
exercise for the reader.

Rick Smith

2007-03-12, 9:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:6dRIh.197862$Wn.83634@fe06.news.easynews.com...
> You may be right (but I am still not certain) for IBM mainframes.
According to:
>
http://publibz.boulder.ibm.com/cgi-...igy3pg32/2.4.54
[I used <
http://publib.boulder.ibm.com/infoc...sp?topic=/com.i
bm.entcobol4.doc/up4060.htm >.]
>
> "TRUNC(STD) applies only to USAGE BINARY receiving fields in MOVE
statements and
> arithmetic expressions."

"receiving fields"; not "sending fields"!

> but it then goes on to say,
> "When TRUNC(STD) is in effect, the final result of an arithmetic
expression,
> ..., is truncated"

And continues with "to the number of digits in the
PICTURE clause of the BINARY receiving field."

> So I am not certain where in your compute statement the truncation would
occur
> (if at all), i.e. for the "arithmetic expression" (evaluation) or in the
FINAL
> move to the receiving field.

Let me emphasize "receiving field".

> I don't (easily) have an Enterprise COBOL system
> to test with, so I can't tell for sure. (I just "in general" HATE to rely
on
> any stage of USAGE BINARY items where the data is larger than the
PICTURE).

And IBM recognizes your concern:

"Recommendations: TRUNC(BIN) is the recommended
option for programs that use binary values set by other
products. Other products, such as IMS, DB2, C/C++,
FORTRAN, and PL/I, might place values in COBOL
binary data items that do not conform to the PICTURE
clause of the data items."

[snip]
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:12v7j5rd1ec59cd@corp.supernews.com...
[snip][color=darkred]
[snip]

Frank Swarbrick

2007-03-12, 9:55 pm

Here's some real life code I have that actually uses this:
01 CHR-USER-RECORD.
10 CHR-SPCLFGS PIC X(04).

77 REISSUE-DISALLOW-BIT PIC S9(8) BINARY VALUE 12.
77 REISSUE-DISALLOWED PIC S9(8) BINARY.

CALL 'CEESITST' USING CHR-SPCLFGS
REISSUE-DISALLOW-BIT
FC
REISSUE-DISALLOWED
IF REISSUE-DISALLOWED = 1
MOVE 'N' TO RISS-ALLOW OF CARD-DTL
ELSE
MOVE 'Y' TO RISS-ALLOW OF CARD-DTL
END-IF

I don't see the need to worry about using PIC X(4) versus PIC S9(9) COMP
other than in the field to be tested (which shouldn't really be thought of
as a number in the first place). The maximum value of parm2 is +31 and the
maximum value of result is +1.
Also, you can't test more than one bit per call.

I used this in this particular situation just because it's available. But
generally we use an assembler program to 'expand' the bits to bytes. We
then use COBOL subscripting to test the bytes for a value of '0' or '1'.

Another caveat to using the LE routine is that it counts right to left and
from 0. In the above example I am testing 'bit 12'. If I used our
bits-to-bytes routine I would check "byte 21".

Then there's the EZACIC06 routine which also does a 'bits to bytes'
expansion, but also reorders things so that they have almost the same
reference as with CEESITST, except that they are 1 - 32 instead of 0 - 31.

If you can make any sense I've what I just said I can only assume you
already know what I'm talking about. :-)

Frank

n 3/12/2007 at 3:32 AM, in message
<579Jh.240693$_X1.83265@fe05.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> Of course the "odd" thing is how you need to create the parms for a call
> to
> CEESITST. The simple fact is that COBOL does *NOT* have (before the '02
>
> Standard and IBM hasn't implemented USAGE BINARY-CHAR or any other
> BINARY-xxx
> usage) a way to specify a
>
> 32-bit integer
>
> The best (non-Standard) way to do this in Enterprise COBOL is to say
> 05 32Int Pic S9(9) Comp-5.
>
> but even THEN it is hard to test the "high-level" bit. In reality, you
> would
> PROBABLY end up passing
> Pic X(4)
> fields to CEESITST (in COBOL) and use hex-literals to set bits that you
> want to
> test, The following is how I *guess* that CEESITST would actually be
> used in
> COBOL (you should note that there is NO "usage" example any where in the
>
> existing LE manuals).
>
> 05 Parm1 Pic S9(9) Comp-5
> 05 Parm2 Pic X(4)
> 05 Reslt Pic S9(9) Comp-5
> ....
> Move to-be-tested to Parm1
> Move 17 to Parm1
> Call "CEESITST" Using Parm1 Parm2 FC Reslt
> If Reslt = 1
> Display "bit 17 - in a way that COBOL never counts - is ON
> Else
> Display "bit 17 is off"
> End-If
>
> ****
>
> As there is NO example of how to use this callable service, I am not
> POSITIVE
> this is correct, but I think it is.

William M. Klein

2007-03-12, 9:55 pm

Frank,
When I posted my example, I thought about the fact that the actual parms with
"numbers" could only be up to 32, so "truncation" with a PIC S9(9) COMP (or
BINARY) field would NOT occur. Furthermore, I know that COMP-5 still isn't
available on VSE. However, for Z/OS, I think that COMP-5 should be used for ALL
"binary" fields passed to LE - just because one never knows "what it will do
with it".

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:45F55862.6F0F.0085.0@efirstbank.com...[color=darkred]
> Here's some real life code I have that actually uses this:
> 01 CHR-USER-RECORD.
> 10 CHR-SPCLFGS PIC X(04).
>
> 77 REISSUE-DISALLOW-BIT PIC S9(8) BINARY VALUE 12.
> 77 REISSUE-DISALLOWED PIC S9(8) BINARY.
>
> CALL 'CEESITST' USING CHR-SPCLFGS
> REISSUE-DISALLOW-BIT
> FC
> REISSUE-DISALLOWED
> IF REISSUE-DISALLOWED = 1
> MOVE 'N' TO RISS-ALLOW OF CARD-DTL
> ELSE
> MOVE 'Y' TO RISS-ALLOW OF CARD-DTL
> END-IF
>
> I don't see the need to worry about using PIC X(4) versus PIC S9(9) COMP
> other than in the field to be tested (which shouldn't really be thought of
> as a number in the first place). The maximum value of parm2 is +31 and the
> maximum value of result is +1.
> Also, you can't test more than one bit per call.
>
> I used this in this particular situation just because it's available. But
> generally we use an assembler program to 'expand' the bits to bytes. We
> then use COBOL subscripting to test the bytes for a value of '0' or '1'.
>
> Another caveat to using the LE routine is that it counts right to left and
> from 0. In the above example I am testing 'bit 12'. If I used our
> bits-to-bytes routine I would check "byte 21".
>
> Then there's the EZACIC06 routine which also does a 'bits to bytes'
> expansion, but also reorders things so that they have almost the same
> reference as with CEESITST, except that they are 1 - 32 instead of 0 - 31.
>
> If you can make any sense I've what I just said I can only assume you
> already know what I'm talking about. :-)
>
> Frank
>
>
> n 3/12/2007 at 3:32 AM, in message
> <579Jh.240693$_X1.83265@fe05.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:

Pete Dashwood

2007-03-12, 9:55 pm

"CG" <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote in message
news:55953$45f4e0a0$4275fbdb$18078@FUSE.NET...
> Pete Dashwood wrote:
>
> First, an obvious point: The reason this approach is applicable is
> because it means that the programmer/user does not have to do anything
> special other than use the service provided... It's part of the system.

So is Java ... :-)

>
> As you would probably expect, please consider that Bill's question was
> very specific to his objection to the implementation of CEE3INF. This
> service is not only explicit to LE, but the '3' in the name makes it even
> more specific to the "S/390" [read mainframe, OS/390, MVS, z/OS, et al]
> environment. Therefore, there is no situation where someone using CEE3INF
> would not also have clear access to the Bit Manipulation services that I
> suggested. [There are, BTW, a set of four services for setting, clearing,
> shifting and testing bits.]

No, I understand that, my reservation was about the case where the bit
string interpretation might be required for cases OTHER than the one Bill
raised.

I wasn't aware he was "objecting" ... seems to me he simply asked what
people would do.

>
> I don't find the binary returned value objectionable because it is highly
> unlikely that you would ever actually translate the value to anything,
> much less a character. You test it with a relatively fast compare and get
> on with the logic.

Sure. It wasn't an objection; just something I noted in passing.
>
> Certainly, if you want to broaden the subject to include all situations of
> bit mangling, then native language [IMHO] is the only way to go.

Certainaly that is an arguable option.

> And, if you are in control of the application design and know you are
> lacking such language, change the design to match the features you do
> have.

Sounds a bit like the tail wagging the dog... :-) Nevertheless, I agree it
is a bit pointless designing stuff that cannot be implemented with the
materials and tools at hand.
>
> Finally, your objection to 'bit mapping' is noted, but a FIND in the
> message text returned your use of the word 'mapping' as the only instance.

Hmmm... I checked each message I have posted to this thread and I can't find
that. Are you sure it wasn't quoted within a message from me? It doesn't
really matter anyway; again it was an observation in passing.

Pete.

William M. Klein

2007-03-12, 9:55 pm

Just a point of clarification (and explanation)

Carl is aware of my OBJECTION to the way that CEE3INF returns its information
(from other ways that we communicate).

As far as the comp.lang.cobol thread goes, I really was interested in exactly
HOW experienced COBOL programmers (both in and out of an IBM LE environment)
would handle the requirement to "decode" the bits within a 1 byte (or larger)
string of bits. I was also interested in how this would be solved in situations
where one is interested in only the single value of a single bit vs the case
where one might want to see the entire "layout" of the string of bits.

I have been interested in responses that were related specially to the LE
environment (z/OS *or* VSE). However, I have also been interested in responses
that represent other (possibly more portable) solutions to the general problem.

--
Bill Klein
wmklein <at> ix.netcom.com

Arnold Trembley

2007-03-13, 3:55 am

Bill,

I just looked a COBOL program in my shop that uses a table with 256
entries. The entries look something like this:

01 BYTE-TABLE-DATA.
05 FILLER PIC X(08) VALUE '00000001'.
05 FILLER PIC X(08) VALUE '00000010'.
05 FILLER PIC X(08) VALUE '00000011'.
05 FILLER PIC X(08) VALUE '00000100'.
And so forth, up to
05 FILLER PIC X(08) VALUE '11111111'.

01 BYTE-TABLE REDEFINES BYTE-TABLE-DATA.
05 DECODED-BYTE OCCURS 256 TIMES PIC X(08).

Then you simply take the byte you want to expand, coerce it into a PIC
S9(4) COMP field (or BINARY or COMP-5), add +1 to it, and use it as
an index to retrieve the 8 byte field that contains ones and zeros.

05 BYTE-SUB PIC S9(4) COMP VALUE ZERO.
05 FILLER REDEFINES BYTE-SUB.
10 FILLER PIC X(01).
10 BIT-MAP-BYTE PIC X(01).

MOVE ZERO TO BYTE-SUB
MOVE SOME-BYTE TO BIT-MAP-BYTE
ADD +1 TO BYTE-SUB
MOVE DECODED-BYTE (BYTE-SUB) TO ....

I haven't benchmarked this, but I suspect it ought to be faster than
division. It is relatively easy to understand and implement.

I'm not saying this is the best way, or the most efficient way. But
it is one way to do it entirely in COBOL.

With kindest regards,

William M. Klein wrote:
> Just a point of clarification (and explanation)
>
> Carl is aware of my OBJECTION to the way that CEE3INF returns its information
> (from other ways that we communicate).
>
> As far as the comp.lang.cobol thread goes, I really was interested in exactly
> HOW experienced COBOL programmers (both in and out of an IBM LE environment)
> would handle the requirement to "decode" the bits within a 1 byte (or larger)
> string of bits. I was also interested in how this would be solved in situations
> where one is interested in only the single value of a single bit vs the case
> where one might want to see the entire "layout" of the string of bits.
>
> I have been interested in responses that were related specially to the LE
> environment (z/OS *or* VSE). However, I have also been interested in responses
> that represent other (possibly more portable) solutions to the general problem.
>

--
http://arnold.trembley.home.att.net/

William M. Klein

2007-03-13, 3:55 am

Actually, it might be interesting to put the "source" for such a problem in a
COPYBOOK and then do a COPY into a NESTED program with the code (where you
"pass" to it the byte you want to "decode" and pass back the decoded
PIC X(8) field.

If you did a COPY SUPPRESSING (IBM extension), you wouldn't even need to see all
the 256 FILLER definitions.

--
Bill Klein
wmklein <at> ix.netcom.com
"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:uupJh.64692$as2.11483@bgtnsc05-news.ops.worldnet.att.net...
> Bill,
>
> I just looked a COBOL program in my shop that uses a table with 256 entries.
> The entries look something like this:
>
> 01 BYTE-TABLE-DATA.
> 05 FILLER PIC X(08) VALUE '00000001'.
> 05 FILLER PIC X(08) VALUE '00000010'.
> 05 FILLER PIC X(08) VALUE '00000011'.
> 05 FILLER PIC X(08) VALUE '00000100'.
> And so forth, up to
> 05 FILLER PIC X(08) VALUE '11111111'.
>
> 01 BYTE-TABLE REDEFINES BYTE-TABLE-DATA.
> 05 DECODED-BYTE OCCURS 256 TIMES PIC X(08).
>
> Then you simply take the byte you want to expand, coerce it into a PIC S9(4)
> COMP field (or BINARY or COMP-5), add +1 to it, and use it as an index to
> retrieve the 8 byte field that contains ones and zeros.
>
> 05 BYTE-SUB PIC S9(4) COMP VALUE ZERO.
> 05 FILLER REDEFINES BYTE-SUB.
> 10 FILLER PIC X(01).
> 10 BIT-MAP-BYTE PIC X(01).
>
> MOVE ZERO TO BYTE-SUB
> MOVE SOME-BYTE TO BIT-MAP-BYTE
> ADD +1 TO BYTE-SUB
> MOVE DECODED-BYTE (BYTE-SUB) TO ....
>
> I haven't benchmarked this, but I suspect it ought to be faster than division.
> It is relatively easy to understand and implement.
>
> I'm not saying this is the best way, or the most efficient way. But it is one
> way to do it entirely in COBOL.
>
> With kindest regards,
>
>
> William M. Klein wrote:
>
> --
> http://arnold.trembley.home.att.net/
>

Clark F Morris

2007-03-13, 6:55 pm

On Mon, 12 Mar 2007 02:36:10 -0500, "Rick Smith" <ricksmith@mfi.net>
wrote:

>
>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>news:55jmglF25132bU1@mid.individual.net...
>[snip]
>
>Thank you for your kind words, here and elsewhere.
>
>This is little more than the implementation, in COBOL,
>of a few assembler instructions. The use of powers of 2
>translates to logical "shift" and "and". For IBM, the inline
>instruction sequence, for those with both functions (and
>this could be used for all), is:
> L
> SRL
> N
> STH
>
>Any who are truly uncomfortable with using COBOL
>to extract bit fields could write an equivalent assembler
>routine and call it.
>
>
When you take into account the inter module calling overhead on IBM z
series, especially with the DYNAM option the following conversion from
a bit switch to a byte-switch is probably quickest. I am assuming
that the field descriptions in the data division are obvious from the
code. I had a nice assembler routine that used UNPK - unpack, NC -
and character and TR to get the switch bytes but the savings in the
routine itself were eaten up by the overhead.

MOVE bit-switch TO binary-field-low-order-character.
MOVE ZERO TO switch-bytes
IF binary-field > 127
SUBTRACT 128 FROM binary-field
MOVE '1' TO switch-byte (1)
END-IF
IF binary-field > 63
SUBTRACT 64 FROM binary-field
MOVE '1' TO switch-byte (2)
END-IF
IF binary-field > 31
SUBTRACT 32 FROM binary-field
MOVE '1' TO switch-byte (3)
END-IF
IF binary-field > 15
SUBTRACT 16 FROM binary-field
MOVE '1' TO switch-byte (4)
END-IF
IF binary-field > 7
SUBTRACT 8 FROM binary-field
MOVE '1' TO switch-byte (5)
END-IF
IF binary-field > 3
SUBTRACT 4 FROM binary-field
MOVE '1' TO switch-byte (6)
END-IF
IF binary-field > 1
SUBTRACT 2 FROM binary-field
MOVE '1' TO switch-byte (7)
END-IF
IF binary-field = 1
MOVE '1' TO switch-byte (8)
END-IF

Sponsored Links