ACCEPT and the SCREEN SECTION.

I am trying to get my (aged) arms around the SCREEN SECTION. I have
examples that DISPLAY fields.
But what I need to learn about is how to enter data.
1. Is the descripton of an entry field essentially the same as that of
a display-only field?
If not, how to I distinguish the two?

2. How do I highight the current data entry field?

3. How do I indicate to the program that I have finished filling in
data and now want to accept the screen.

I use htcobol at the moment.  Open Cobol doesn't do screens, or even
positioned ACCEPT and DISPLAY.

I bought a fairly recent book but it only shows the pretty picture
verson of the SCREEN SECTION, not the  fill in forms.

John Culleton

john@wexfordpress.com wrote:
> I am trying to get my (aged) arms around the SCREEN SECTION. I have
> examples that DISPLAY fields.
> But what I need to learn about is how to enter data.
> 1. Is the descripton of an entry field essentially the same as that of
> a display-only field?
> If not, how to I distinguish the two?
>
> 2. How do I highight the current data entry field?
>
> 3. How do I indicate to the program that I have finished filling in
> data and now want to accept the screen.
>
> I use htcobol at the moment.  Open Cobol doesn't do screens, or even
> positioned ACCEPT and DISPLAY.
>
> I bought a fairly recent book but it only shows the pretty picture
> verson of the SCREEN SECTION, not the  fill in forms.
>
> John Culleton
>

Never heard of "htcobol" !

The syntax and extensions are very specific to Micro Focus products, but
as a guideline take a look at their on-line manual dealing with Screen
Section - might give you some tips :-

http://supportline.microfocus.com/s...ndx.ht
m

then from the 'BookShelf' under 'Programming' select "Character User
Interface"

Jimmy

John,
It may be worth noting (implied by Jimmy's response) that there are 4 (mediu
m)
distinct Accept/Display variations:

1) X/Open (Micro Focus is a super-set of this)

2) Distinct vendor versions of the X/Open definition (Micro Focus and RM are
 the
most common versions of this)

3) AcuCOBOL has an EXTENDED version allowing (supporting) GUI's via
Accept/Display

4) ANSI/ISO 2002 (processor dependent) variation - this started with the X/O
pen
definition but MODIFIED (slightly).

Bottom-Line:
Portability of Accept/Display/Screen Section should NOT be expected !!!


--
Bill Klein
wmklein <at> ix.netcom.com
<john@wexfordpress.com> wrote in message
news:1151705295.354915.17170@b68g2000cwa.googlegroups.com...
>I am trying to get my (aged) arms around the SCREEN SECTION. I have
> examples that DISPLAY fields.
> But what I need to learn about is how to enter data.
> 1. Is the descripton of an entry field essentially the same as that of
> a display-only field?
> If not, how to I distinguish the two?
>
> 2. How do I highight the current data entry field?
>
> 3. How do I indicate to the program that I have finished filling in
> data and now want to accept the screen.
>
> I use htcobol at the moment.  Open Cobol doesn't do screens, or even
> positioned ACCEPT and DISPLAY.
>
> I bought a fairly recent book but it only shows the pretty picture
> verson of the SCREEN SECTION, not the  fill in forms.
>
> John Culleton
>

William M. Klein wrote:
> John,
>   It may be worth noting (implied by Jimmy's response) that there are 4 (m
edium)
> distinct Accept/Display variations:
>
> 1) X/Open (Micro Focus is a super-set of this)
>
> 2) Distinct vendor versions of the X/Open definition (Micro Focus and RM a
re the
> most common versions of this)
>
> 3) AcuCOBOL has an EXTENDED version allowing (supporting) GUI's via
> Accept/Display
>
> 4) ANSI/ISO 2002 (processor dependent) variation - this started with the X
/Open
> definition but MODIFIED (slightly).
>
> Bottom-Line:
>    Portability of Accept/Display/Screen Section should NOT be expected !!!
>
>
OK Bill X/Open 101 :-) In brief exactly what is this X/Open. I've seen
it referred to again and again - BUT *exactly* what is it ?

Jimmy

In article <_YXrg.132524$iF6.91328@pd7tw2no>, "James J. Gavan" <jgavandeletethis@shaw.ca> w
rites: 
> OK Bill X/Open 101 :-) In brief exactly what is this X/Open. I've seen
> it referred to again and again - BUT *exactly* what is it ?

X/Open Company Ltd was formed in the 1980s to promulgate "open
systems standards" - one of the various attempts to turn Unix user
groups into more-effective lobbying agents for selling Unix to big
business and government, against the dominant mainframe systems.

It preceeded UNIX International, formed by AT&T and Sun, and the
competing Open Software Foundation, formed by most of the other Unix
vendors.  While UI and OSF battled it out, mostly over how prominent
AT&T's UNIX System V would be, X/Open was issuing one standard after
another.  Since X/Open wasn't a government body, these standards
didn't have any special force, but in some markets they were taken
up as useful references.

Thus X/Open "branding" became a touchstone for procurement in some
organizations.

The most influential X/Open efforts are its early-1990s definitions
of the Unix system APIs (XSI) and commands (XPG4); its 1994 Spec
1170, which evolved into the Single UNIX Specification; and its UNIX
95 brand, which was the first real use of the UNIX trademark to
indicate that a vendor's Unix implementation was "standard".  But it
issued standards for numerous other things as well - including COBOL.
(My guess is that was part of an effort to convince businesses that
they could migrate mainframe COBOL applications to UNIX.)

In 1996, X/Open merged with OSF to become The Open Group.  The Open
Group continued to publish the Single UNIX Specification.  In 2001,
SUSv3 consolidated all the prominent Unix specs - SUS, IEEE's POSIX,
and ISO/IEC 9945 - into a single international specification for
Unix.

You can find the X/Open COBOL spec on the Open Group website, as a
free PDF; at 196 pages, it's a breeze, compared to the ANSI 2002
spec.  According to the blurb, X/Open COBOL is based on COBOL 85,
without the optional modules (Report Writer, etc).  It doesn't
appear to have been updated since 1991.

--
Michael Wojcik                  michael.wojcik@microfocus.com

Even if Jesus set up a blogging cafe in the center of Rockport, Texas
and extolled the virtues of a woman's right to choose while snapping
pictures of gay weddings with his Nokia, it would have made no
difference to this election.   -- Ashlee Vance

Michael Wojcik wrote:
> In article <_YXrg.132524$iF6.91328@pd7tw2no>, "James J. Gavan" <jgavandele
tethis@shaw.ca> writes:
> 
>
>
> X/Open Company Ltd was formed in the 1980s to promulgate "open
> systems standards" - one of the various attempts to turn Unix user
> groups into more-effective lobbying agents for selling Unix to big
> business and government, against the dominant mainframe systems.

<snip>

Thanks for the detailed reply Michael.

The only thing I ever used back in RM/COBOL days, (early 80's) was
Microsoft Xenix. Obviously their own but did that fit the X/Open pattern
for Unix ? I note from the latest M/F Tech Update that they support,
with separate compilers, something like a dozen or more flavours of
Unix/Linux type OS - Susie for one and perhaps Samba ?.

Care to cover the next as a separate topic - Virtual Machines. Let's
stick with Smalltalk. Back in Xerox PARC days whichever black box they
used they produced a Smalltalk VM. (Interestingly just re-read something
Adele Goldberg wrote. As a member of that early team she makes the same
comment you did - PARC did a lousy job promoting Smalltalk). PARC has
broken away from Xerox as a separate entity, so not sure exactly what
they do now.

Then you move on to their Smalltalk 80 standard - only 89 pages ! Not
surprising really - specify how and when objects are created and the
rest is in your various support classes. However I haven't seen any
mention of a Smalltalk 80 compiler. The only two I'm aware of
commercially are CINCOM (?) uses Visual Works (?) and Dolphin which has
its own active newsgroup.

I've downloaded Squeak to take a look - and reading up on it I see it
uses C for the VM. Having got it figured out themselves back at PARC -
why a move to C ?

Was a VM ever a possibility for COBOL compiler vendors - WITHOUT using C
? (Bill was this ever a topic in COBOL Standards ?).

That 'thinggy' you did in the M/F Forum. Would love to see an
explanation and  sample of a program using hashing with M/F Collections
:-). That's assuming of course there is an advantage for using hashing
over and above existing non-hash methods.

Jimmy

In article <l_zsg.146932$iF6.68300@pd7tw2no>, "James J. Gavan" <jgavandeletethis@shaw.ca> w
rites:
>
> The only thing I ever used back in RM/COBOL days, (early 80's) was
> Microsoft Xenix. Obviously their own but did that fit the X/Open pattern
> for Unix ?

I don't think Xenix was ever compatible with the X/Open standards.
MS Xenix was actually an OEM-only product, apparently, which was
turned into a consumer product by SCO for x86 machines, and also by
some hardware OEMs for other architectures.  MS eventually sold
Xenix outright to SCO (in exchange for partial ownership of the
latter) in 1987.

Original Xenix was based on AT&T Unix System III, which preceeded
X/Open.  Xenix was later upgraded to a System V port (plus
extensions), which would have been more suitable for X/Open
compatibility, but I don't believe SCO ever made that effort under
the Xenix brand.  In 1989, they turned Xenix into SCO UNIX.

AT&T incorporated elements of Xenix into System V Release 4 (SVR4),
which heavily influenced later X/Open standards, so Xenix did have
some influence on X/Open.

In its heyday, Xenix ran on more machines than any other flavor of
Unix - though that was largely because it took a lot of x86 boxes to
do anything useful.

> I note from the latest M/F Tech Update that they support,
> with separate compilers, something like a dozen or more flavours of
> Unix/Linux type OS - Susie for one and perhaps Samba ?.

SuSE is a Linux "distribution", now owned by Novell.  (Linux itself
is just an OS kernel.  To make a useful OS, you have to take some
build of the kernel - which could be any version of the core kernel,
plus any number of kernel modules - and combine it with all the
user-space utilities and applications required to make a functional
OS for your purposes, plus whatever extra goodies you might want.
That's a distribution.)

Samba is an open-source implementation of the SMB filesharing
protocol (the protocol used by Microsoft).

I think the current version of MF Server Express is available for
more than forty Unix/Linux platforms.  That's Unix implementations
and Linux distributions, at various supported release levels, for
various CPUs, 32- and 64-bit.

--
Michael Wojcik                  michael.wojcik@microfocus.com

The surface of the word "profession" is hard and rough, the inside mixed wit
h
poison.  It's this that prevents me crossing over.  And what is there on the
other side?  Only what people longingly refer to as "the other side".
-- Tawada Yoko (trans. Margaret Mitsutani)

In article <l_zsg.146932$iF6.68300@pd7tw2no>, "James J. Gavan" <jgavandeletethis@shaw.ca> w
rites:
>
> Care to cover the next as a separate topic - Virtual Machines. Let's
> stick with Smalltalk. Back in Xerox PARC days whichever black box they
> used they produced a Smalltalk VM.
>
> Then you move on to their Smalltalk 80 standard - only 89 pages ! Not
> surprising really - specify how and when objects are created and the
> rest is in your various support classes. However I haven't seen any
> mention of a Smalltalk 80 compiler....

I don't know of one offhand, but I haven't used Smalltalk in years.

> I've downloaded Squeak to take a look - and reading up on it I see it
> uses C for the VM. Having got it figured out themselves back at PARC -
> why a move to C ?

I'm not sure I understand the question.  Those PARC VMs had to be
written in something.  If the Squeak VM were written in Smalltalk,
you'd need a Smalltalk compiler on the target system before you could
use Squeak, which would make Squeak a bit redundant.

> Was a VM ever a possibility for COBOL compiler vendors - WITHOUT using C?

MF int-code is an interpreted intermediate code.  It's debatable
whether the MF COBOL runtime is a "VM" (depends on how you define
a VM), but we do support intermediate interpreted code that's
portable to some extent.  And while the runtime is written in a
combination of COBOL, C, and C++, it could be written in another
language.

--
Michael Wojcik                  michael.wojcik@microfocus.com

The lecturer was detailing a proof on the blackboard.  He started to say,
"From the above it is obvious that ...".  Then he stepped back and thought
deeply for a while.  Then he left the room.  We waited.  Five minutes
later he returned smiling and said, "Yes, it is obvious", and continued
to outline the proof.  -- John O'Gorman

In article <l_zsg.146932$iF6.68300@pd7tw2no>, "James J. Gavan" <jgavandeletethis@shaw.ca> w
rites:
>
> That 'thinggy' you did in the M/F Forum. Would love to see an
> explanation and sample of a program using hashing with M/F Collections
> :-). That's assuming of course there is an advantage for using hashing
> over and above existing non-hash methods.

Wrong kind of hashing, I think.

MD5, which is what my sample program from the MF Forum computes, is a
cryptographic hash.  Cryptographic hashes are intended to distinguish
documents: they're supposed to be virtually collision-free and resist
creating collisions.

General-purpose hashes, for hash tables and similar data structures,
have different requirements.  They should have a low probability of
collision for anticipated input (which in some cases means for
random input), but more importantly they should be very fast, and
their output should be convenient to work with.

Cryptographic hashes try to be relatively fast, but they're not
nearly as fast as general-purpose hashes.  And their output has to
be relatively large.  MD5's output is 128 bits, and that's now
considered too short; current security applications should use
cryptographic hashes with at least 256 bits of output.

If you're implementing a hash table, you don't want your hash value
to be 16 or 32 bytes; at that point you might as well just use the
original key.

In short, cryptographic hashes like MD5 are used to verify data,
while general-purpose hashes are used to index it.

Now, I do know of at least one widely-used application that uses MD5
hashes as an index: BitTorrent.  BitTorrent servers publish the MD5
hashes of chunks of data that they can distribute, and BitTorrent
clients request chunks by MD5 hash.  Since the possiblity of a
collision is very very low, if a client asks for and receives a chunk
that has a particular MD5 hash value, it's very very likely to be the
piece of data it's looking for.

But that's a special case.  BitTorrent is essentially trying to index
every "interesting" chunk of data of a certain size in the entire
world.  Most hash tables are a bit less ambitious, so they do better
with smaller, faster hashes.


All that said, hash tables are a classic type of collection in OO
programming.  I see there's discussion of creating custom hash
methods for collections in the MF docs, though I've never looked into
this.  It'd be interesting to try to implement one of the current
well-regarded hash functions (such as Bob Jenkins's, or Paul Hsieh's,
or Chunk Falconer's) in COBOL as a collection hash method.  The
popular hashes tend to use bit-manipulation and other techniques that
don't work well in COBOL (they're difficult to implement efficiently
and portably), and they tend to be at least somewhat CPU-specific,
which means they may work slowly, if at all, on other CPUs.

For a COBOL hash of alphanumeric data, I'd probably just go with a
linear-congruential algorithm.  In untested, MF-specific code,
something like:

data division.
working-storage section.

77  hash-value               pic x(4) comp-5.
77  char-value               pic x comp-5.
77  string-idx               pic x(4) comp-5.

linkage section.

77  in-string                pic x.
77  in-len                   pic x(4) comp-5.

procedure division using in-string in-len.

move 0 to hash-value
perform varying string-idx from 1 by 1 until string-idx > in-len
move in-string(string-idx:1) to char-value
multiply 65599 by hash-value
add char-value to hash-value
end-perform
goback returning hash-value
end program.

The constant multiplier should probably be prime; since the increment
(the value of the next character) is unpredictable, we don't have any
other way of reducing the probability of short cycles.  One reference
(Aho, Sethi, and Ulman) recommends 65599 for a 32-bit hash, so that's
what I used.

--
Michael Wojcik                  michael.wojcik@microfocus.com

O sometimes, nevertheless,
The labourer at his instrument or tractor,
Bending into a state of merge with objects,
Finds the same love that, from a machine of sex,
Steps down as Venus to her invoker.			-- George Barker