Re: How would you do this?


"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:12v6pek1atd1a64@xxxxxxxxxxxxxxxxxxxxx

"William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
news:rrDIh.242220$k82.140284@xxxxxxxxxxxxxxxxxxxxxxxxx
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)
-----



Excellent! Great stuff, Rick.

Pete.


.

Relevant Pages

  • Re: How would you do this?
    ... IBM has recently created an LE callable service, CEE3INF, ... my question is how various "experienced" COBOL programmers would ... environments for those who see this note and don't work in IBM mainframe ...
    (comp.lang.cobol)
  • Re: "Shared" procedure division code
    ... I already said my comments applied to the IBM ... There is no question of contempt for other environments (or ... devoid of an edge of categorical contempt, ... > would suggest that the Unisys MCP is your WHOLE universe and you are ...
    (comp.lang.cobol)
  • Re: IBM... the true meaning
    ... > Was wondering if anybody has any good expansions of IBM... ... > been working with their horrible J2EE containers/development ... > environments and been as frustrated as I am with them you might have ...
    (comp.lang.java.programmer)
  • Re: Scripts & Communications
    ... >> Want to guess when IBM gave up EBCDIC? ... device jumper. ... They laugh at COBOL programmers. ... They can read that core dump like it was source code. ...
    (sci.crypt)
  • IBM... the true meaning
    ... Was wondering if anybody has any good expansions of IBM... ... been working with their horrible J2EE containers/development ... environments and been as frustrated as I am with them you might have ...
    (comp.lang.java.programmer)