From: William M. Klein on
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 Klein
wmklein <at> ix.netcom.com


From: Rick Smith on

"William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message
news:rrDIh.242220$k82.140284(a)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-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.

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)
-----



From: William M. Klein on
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(a)mfi.net> wrote in message
news:12v6pek1atd1a64(a)corp.supernews.com...
>
> "William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message
> news:rrDIh.242220$k82.140284(a)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-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.
>
> 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)
> -----
>
>
>


From: Louis Krupp on
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")

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.

The good thing is that the C code wouldn't have to know what any of the
bits meant, and you wouldn't have to do anything fancy in COBOL to get
the information you need.

Louis
From: Louis Krupp on
Louis Krupp wrote:
> 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")
>
> 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