Home > Archive > Cobol > June 2004 > Issues with MOVE CORRESPONDING and REDFINED records?
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 |
Issues with MOVE CORRESPONDING and REDFINED records?
|
|
| Paul Raulersonv 2004-06-09, 3:55 pm |
| Are there any particular known issues with using MOVE CORRESPONDING from a redefined record? Coincidentally, I just got bit, in a most embarrassing manner, doing just that on an AS/400. I was wondering if this is a general issue, or something particular to OS/400? I've never had problems doing that before under OS/390, which is one reason it snuck up on me and left toothmarks.
Thanks
-Paul
| |
| Frederico Fonseca 2004-06-09, 3:55 pm |
| On Wed, 09 Jun 2004 15:52:27 GMT, "Paul Raulersonv"
<pkrauleson@verizon.net> wrote:
>Are there any particular known issues with using MOVE CORRESPONDING from a redefined record? Coincidentally, I just got bit, in a most embarrassing manner, doing just that on an AS/400. I was wondering if this is a general issue, or something particular
to OS/400? I've never had problems doing that before under OS/390, which is one reason it snuck up on me and left toothmarks.
>
>Thanks
>-Paul
It can.
Which COBOL (ILE or OPM) and please post code.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| Paul Raulersonv 2004-06-13, 3:55 pm |
| ILE Cobol, some with SQL preprocessing if it makes any difference.
Without posting a ton of code, it is basically an issue where the input and output
DDS definitions for a transaction file (i.e. workstation) do not match. This happens,
say, when you have more output fields than input fields.
"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message news:4kgec0lgjdj3tsc5qfl9lnms5t9lc2ood9@
4ax.com...
> On Wed, 09 Jun 2004 15:52:27 GMT, "Paul Raulersonv"
> <pkrauleson@verizon.net> wrote:
>
most embarrassing manner, doing just that on an AS/400. I was wondering if this is a general issue, or something particular to
OS/400? I've never had problems doing that before under OS/390, which is one reason it snuck up on me and left toothmarks.[color=darkred]
>
> It can.
>
> Which COBOL (ILE or OPM) and please post code.
>
>
>
>
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com
| |
| Frederico Fonseca 2004-06-13, 3:55 pm |
|
On Sun, 13 Jun 2004 14:56:42 GMT, "Paul Raulersonv"
<pkrauleson@verizon.net> wrote:
Top posting corrected
>
>"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message news:4kgec0lgjdj3tsc5qfl9lnms5t9lc2ood9@
4ax.com...
>most embarrassing manner, doing just that on an AS/400. I was wondering if this is a general issue, or something particular to
>OS/400? I've never had problems doing that before under OS/390, which is one reason it snuck up on me and left toothmarks.
>
>ILE Cobol, some with SQL preprocessing if it makes any difference.
>Without posting a ton of code, it is basically an issue where the input and output
>DDS definitions for a transaction file (i.e. workstation) do not match. This happens,
>say, when you have more output fields than input fields.
>
the SQL bit should not matter unless this is part of the MOVE. Don't
think so for what you've said.
What exactly is your problem??
As far as I have done so far the move corr will work fine, but you
need to redefine these on working instead of the FD itself. (NEVER
leave them defined on the FD, as this will definitelly BITE you!!)
The fact that the number of fields are not the same should not matter
on this case, unless you have some weird DDS.
If you with please post the error you are getting, along with the
Select/FD definition from the compiler listing.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| Paul Raulersonv 2004-06-13, 3:55 pm |
| It is difficult to cut/paste code from an AS/400 screen into this with the particular
setup I am using right now. Basically, I did move corresponding from the FD record
space to the working storage space, and then a move corresponding back, and the program
will crater on the move back.
I've gotten around this, on the advice of others, by making all the fields I/O and
just setting a protect bit on the fields I don't want the user to monkey with (again,
that is a very BMS-like way to deal with the issue).
Would you mind if I e-mailed you the listing? If not, then please drop me a line with your
e-mail address and I'll move this offline where I can cut/paste with more facility.
Thanks
-Paul Raulerson
paul @ raulersons dot com
"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message news:pkroc09hfknhm1le0ppeuib61poi2e2olf@
4ax.com...
>
> On Sun, 13 Jun 2004 14:56:42 GMT, "Paul Raulersonv"
> <pkrauleson@verizon.net> wrote:
> Top posting corrected
>
in a[color=darkred]
> the SQL bit should not matter unless this is part of the MOVE. Don't
> think so for what you've said.
>
> What exactly is your problem??
>
> As far as I have done so far the move corr will work fine, but you
> need to redefine these on working instead of the FD itself. (NEVER
> leave them defined on the FD, as this will definitelly BITE you!!)
> The fact that the number of fields are not the same should not matter
> on this case, unless you have some weird DDS.
>
> If you with please post the error you are getting, along with the
> Select/FD definition from the compiler listing.
>
>
>
>
>
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com
| |
| Frederico Fonseca 2004-06-13, 3:55 pm |
| On Sun, 13 Jun 2004 15:46:59 GMT, "Paul Raulersonv"
<pkrauleson@verizon.net> wrote:
Top-posting corrected.
>
>"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message news:pkroc09hfknhm1le0ppeuib61poi2e2olf@
4ax.com...
>in a
snip
[color=darkred]
>
>It is difficult to cut/paste code from an AS/400 screen into this with the particular
>setup I am using right now. Basically, I did move corresponding from the FD record
>space to the working storage space, and then a move corresponding back, and the program
>will crater on the move back.
>
>I've gotten around this, on the advice of others, by making all the fields I/O and
>just setting a protect bit on the fields I don't want the user to monkey with (again,
>that is a very BMS-like way to deal with the issue).
>
>Would you mind if I e-mailed you the listing? If not, then please drop me a line with your
>e-mail address and I'll move this offline where I can cut/paste with more facility.
>Thanks
>-Paul Raulerson
>paul @ raulersons dot com
>
>
Look at my sig and email the listing to me.
As for cut+paste from the 400 spool file, the best is to copy the SPLF
to a db file (CPYSPLF command), and then ftp this to your PC, and then
use notpad to get the listing.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
|
|
|
|
|