Home > Archive > Cobol > June 2007 > MEMO field comparison
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
MEMO field comparison
|
|
| Rene_Surop 2007-06-13, 9:55 pm |
| 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?
| |
| Thomas 2007-06-13, 9:55 pm |
| 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
| |
| Lovelin 2007-06-14, 9:55 pm |
| 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.
| |
| William M. Klein 2007-06-15, 7:55 am |
| Whether or not you can have a 64k field within a single record in a file defined
and used by a COBOL program is "implementation defined". I know some compilers
(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 defined
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.
>
| |
| Rene_Surop 2007-06-17, 6:55 pm |
| 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
| |
| Pete Dashwood 2007-06-18, 3:55 am |
|
"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.
| |
| Rene_Surop 2007-06-18, 9:56 pm |
| 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.
| |
| Lovelin 2007-06-19, 9:55 pm |
| What is the maximum length of existing data on that field?
| |
|
|
|
|
|