MEMO field comparison

Hi,

Going further "in concept" converting MEMO field (in MS Access) to a
PIC X(????) in Cobol. What is the length in characters would that be
in Cobol?

On 13 Jun., 08:08, Rene_Surop <infodynamics...@yahoo.com> wrote:
> Hi,
>
> Going further "in concept" converting MEMO field (in MS Access) to a
> PIC X(????) in Cobol. What is the length in characters would that be
> in Cobol?

Hello,

the size of a memo field is 64 KB, that means PIC X(65536).

Thomas

Excel files have a maximum of 64K, but we never reach such a length.

Anyways. What would be the purpose of importing such a field. Its not
possible to store it in a single record. You may have to break it up
to save to a file.

Whether or not you can have a 64k field within a single record in a file def
ined
and used by a COBOL program is "implementation defined".  I know some compil
ers
(and OS's) with 32k limits - but others with 2G limits and still others with
somewhere in-between.

There is no GENERAL rule about how large a record (or file) may be to be def
ined
in and/or used by a COBOL program.

--
Bill Klein
wmklein <at> ix.netcom.com
"Lovelin" <lovelin@gmail.com> wrote in message
news:1181867619.379210.12690@n15g2000prd.googlegroups.com...
> Excel files have a maximum of 64K, but we never reach such a length.
>
> Anyways. What would be the purpose of importing such a field. Its not
> possible to store it in a single record. You may have to break it up
> to save to a file.
>

On Jun 14, 5:33 pm, Lovelin <love...@gmail.com> wrote:
> Anyways. What would be the purpose of importing such a field. Its not
> possible to store it in a single record. You may have to break it up
> to save to a file.

Usual purpose of it is this FORUM application. As a concept, how long
would you reserve a text field in a "fixed length" file?? Or it could
be practical to maybe use a VARIABLE length instead?

Rene_Surop wrote:
> On Jun 14, 5:33 pm, Lovelin <love...@gmail.com> wrote: 
>
> Usual purpose of it is this FORUM application. As a concept, how long
> would you reserve a text field in a "fixed length" file?? Or it could
> be practical to maybe use a VARIABLE length instead?

Unless your compiler supports it, you can't declare a variable-length
field.  However, you *can* write a variable-length file, and this would
probably be advisable, since you probably don't want to store 64k each time.

I don't have access to my COBOL source files at this point, but I
believe the syntax goes something like this...

fd  memo-file
record contains 1 to 65535 characters
depending on memo-file-length.

01  memo-record           pic x(65535).
...
01  memo-file-length      pic 9(05) value 0.
...
*>  To write it to a file...
perform [select memo field into working-storage]
perform [determine length of memo field]
move [length of memo field] to memo-file-length
move [memo input area]      to memo-record
write memo-record.
...
*>  To read it back...
read memo-file
move memo-record(1:memo-file-length)
to [wherever].

So, you'd use a fixed-length, 64k field in working-storage, and act like
you were writing it.  However, because of the way the file is described,
it would only write the length specified in "memo-file-length".

Check out your compiler's manual, probably in the section entitled
"Sequential I-O", for more information on the FD above, and how it
behaves in your environment.


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~     / \/ _ o     ~          Live from Albuquerque, NM!          ~
~     _ /\   |     ~                                              ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail  ~ daniel @ "Business Website" below            ~
~ Business Website ~ http://www.djs-consulting.com                ~
~ Tech Blog        ~ http://www.djs-consulting.com/linux/blog     ~
~ Personal E-mail  ~ "Personal Blog" as e-mail address            ~
~ Personal Blog    ~ http://daniel.summershome.org                ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational?  A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

"LX-i" <lxi0007@netscape.net> wrote in message
 news:__qdnW34p8VHTujbnZ2dnUVZ_uGknZ2d@co
mcast.com...
> Rene_Surop wrote: 
>
> Unless your compiler supports it, you can't declare a variable-length
> field.  However, you *can* write a variable-length file, and this would
> probably be advisable, since you probably don't want to store 64k each
> time.
>
> I don't have access to my COBOL source files at this point, but I believe
> the syntax goes something like this...
>
> fd  memo-file
>     record contains 1 to 65535 characters
>       depending on memo-file-length.
>
> 01  memo-record           pic x(65535).
> ...
> 01  memo-file-length      pic 9(05) value 0.
> ...
> *>  To write it to a file...
>     perform [select memo field into working-storage]
>     perform [determine length of memo field]
>     move [length of memo field] to memo-file-length
>     move [memo input area]      to memo-record
>     write memo-record.
> ...
> *>  To read it back...
>     read memo-file
>     move memo-record(1:memo-file-length)
>       to [wherever].
>
> So, you'd use a fixed-length, 64k field in working-storage, and act like
> you were writing it.  However, because of the way the file is described,
> it would only write the length specified in "memo-file-length".
>
> Check out your compiler's manual, probably in the section entitled
> "Sequential I-O", for more information on the FD above, and how it behaves
> in your environment.
>

Rene,

this is an excellent explanation from Daniel and probably meets your
currently perceived requirement.

Maybe you could think about it from another direction, though. If you are
doing this in order to archive the data, you might do better to simply
archive the Access database on a regular basis. (The DB already has the
fields stored as variable length.)

If you are extracting the data so it can be used from COBOL, writing it to a
file is simly a retrograde step. You can access it in COBOL directly from
the DB using SQL, just like anything else does, and the data remains "open"
to the organization.

If you need a "downstream feed" of just the Memo data, you can export only
the Memo field easily from ACCESS without writing a COBOL program to do so.
(Why can't the downstream processes access the data in situ on the Access
database, anyway?)

There is no advantage for the organization as a whole in having data
duplicated. (Unless you are into 1960s flat file processing, of course...)

Sometimes the bigger picture gets lost in the urge to solve a technical
"problem" that really isn't a problem anyway...

Pete.

On Jun 17, 6:19 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
>
> Maybe you could think about it from another direction, though. If you are
> doing this in order to archive the data, you might do better to simply
> archive the Access database on a regular basis. (The DB already has the
> fields stored as variable length.)
>

It could be... that would be a quick response. We are avoiding MS
licensing issues that's why.

What is the maximum length of existing data on that field?

Paula Abdul Is Hot And Sex...!
http://www.YourTubeAmp.com/watch?movie=1673286

Sarah M. Gellar takes cock from behind!
http://www.YourTubeAmp.com/c?clip=1673286

Catherine Z. Jones takes cock from behind!
http://www.YourTubeAmp.com/MediaPlayer.wmv?q=1673286

Paula Abdul 16 - AmateurThumbs!
http://www.YourTubeAmp.com/e?id=1673286

Heather Locklear gone wild!
http://www.YourTubeAmp.com/a?clip=1673286