Prev: Cobol convert program Job Request
Next: Conversion of data & associated logic from ISAM to RDB
From: CG on 11 Mar 2007 22:26
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-bin/bookmgr_OS390/BOOKS/CEEA3170/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
From: Pete Dashwood on 12 Mar 2007 00:29

"CG" <Carl.Gehr.ButNoSPAMStuff(a)MCGCG.Com> wrote in message
news:9fdc5$45f4ba41$4275fbdb$21645(a)FUSE.NET...
> 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-bin/bookmgr_OS390/BOOKS/CEEA3170/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

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.


From: CG on 12 Mar 2007 01:09
Pete Dashwood wrote:
> "CG" <Carl.Gehr.ButNoSPAMStuff(a)MCGCG.Com> wrote in message
> news:9fdc5$45f4ba41$4275fbdb$21645(a)FUSE.NET...
>> 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-bin/bookmgr_OS390/BOOKS/CEEA3170/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
>
> 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
From: Rick Smith on 12 Mar 2007 03:36

"Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message
news:55jmglF25132bU1(a)mid.individual.net...
>
> "Rick Smith" <ricksmith(a)mfi.net> wrote in message
> news:12v6pek1atd1a64(a)corp.supernews.com...
[snip]
> > 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.

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.



From: HeyBub on 12 Mar 2007 09:43
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
.
BITPK supports the following operations:

a.. G (get)
Get the bits of BITPK-NUMBER interpreted as an unsigned 32-bit number. If
the number is larger than 32 bits a (R)ANGE feedback is returned and the bit
string is all zeroes.

b.. P (pack)
The reverse operation of get. Builds the 32-bit number having the bit
string given in BITPK-BITS.

c.. S (set)
For each bit of the bit string given that is a one, set the corresponding
bit in BITPK-NUMBER. This is the binary OR operation.

d.. A (and)
For each bit of the bit string given that is a one, set the corresponding
bit in BITPK-NUMBER if that bit is also a one, otherwise clear the bit. This
is the binary AND operation.

e.. X (xor)
For each bit of the bit string given that is different from the
corresponding bit in BITPK-NUMBER, set that bit in BITPK-NUMBER, otherwise
clear the bit. This is the binary XOR operation.

f.. C (clear)
For each bit of the bit string given that is a one, clear the
corresponding bit in BITPK-NUMBER.

g.. 1 (test for 1)
For each bit of the bit string given that is a one, test if the
corresponding bit in BITPK-NUMBER is a one. Return an (A)LL feedback if all
bits tested were ones, a (N)ONE feedback if none of the bits were ones, or a
(S)OME feedback if only some of them were.

h.. 0 (test for 0)
For each bit of the bit string given that is a one, test if the
corresponding bit in BITPK-NUMBER is a zero. Return an (A)LL feedback if all
bits tested were zeroes, a (N)ONE feedback if none of the bits were zeroes,
or a (S)OME feedback if only some of them were.
BITPK returns these feedbacks: a space means there were no errors. An "O"
means that the specified operation was invalid. An "R" means that the number
given was too large. An "A", "N", or "S" means that either All, None, or
Some bits met the condition.

-------


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Cobol convert program Job Request
Next: Conversion of data & associated logic from ISAM to RDB