Windows Server

Crasch · Guest

Hi,
I need to use a separator to separate different areas.
I need a way to be sure that this separator is unique and no other
fields gets the same value.
I thought about using 3 byte with value 0x02 for the initial separator
(IN-INITSEPx) and 3 byte with value 0x02 for the ending one
(IN-ENDSEPx).
The problem is that, if we use COMP-3 data types, this value can be
inserted in the area content:
in fact if I put in a PIC 9(6) COMP-3 a value of 20202 i get exactly 3
bytes with a value of 0x02.

We could use a larger field, say 20 bytes, to higher the statistical
probability of a duplication.... but didn't solve the problem.
Any idea on how to resolve this?

10 IN-DATA. INPUT
15 IN-PRESFUNC1 PIC 9(1) DISPLAY. INPUT
15 IN-FUNC1 OCCURS 1 TIMES DEPENDING ON IN-PRESFUNC1.
25 IN-INITSEP1 PIC X. INPUT
25 IN-INITSEP2 PIC X. INPUT
25 IN-INITSEP3 PIC X. INPUT
25 IN-FUNCID PIC X(20). INPUT
25 IN-DATA1 PIC X(10). INPUT
25 IN-DATA2 PIC S9(15)V9(3) DISPLAY.INPUT
25 IN-ENDSEP1 PIC X. INPUT
25 IN-ENDSEP2 PIC X. INPUT
25 IN-ENDSEP3 PIC X. INPUT
15 IN-PRESFUNC2 PIC 9(1) DISPLAY. INPUT
15 IN-FUNC2 OCCURS 1 TIMES DEPENDING ON IN-PRESFUNC2.
25 IN-INITSEP11 PIC X. INPUT
25 IN-INITSEP21 PIC X. INPUT
25 IN-INITSEP31 PIC X. INPUT
25 IN-FUNCID1 PIC X(20). INPUT
25 IN-DATA11 PIC X(10). INPUT
25 IN-DATA21 PIC S9(15)V9(3) DISPLAY.INPUT
25 IN-ENDSEP11 PIC X. INPUT
25 IN-ENDSEP21 PIC X. INPUT
25 IN-ENDSEP31 PIC X. INPUT

thanks
Carlo Folini

Terry Bullington [MSFT] · Guest

I can't think of any way to define some type of "word mark" value that
won't have the possibility of being duplicated. Can you explain the need
for this? Have you considered using a length in front of the fields?
--------------------
From: "Crasch" <carlo.folini@gmail.com>
Newsgroups: microsoft.public.hiserver.general
Subject: Area separator
Date: 3 Mar 2005 06:05:34 -0800

Hi,
I need to use a separator to separate different areas.
I need a way to be sure that this separator is unique and no other
fields gets the same value.
I thought about using 3 byte with value 0x02 for the initial separator
(IN-INITSEPx) and 3 byte with value 0x02 for the ending one
(IN-ENDSEPx).
The problem is that, if we use COMP-3 data types, this value can be
inserted in the area content:
in fact if I put in a PIC 9(6) COMP-3 a value of 20202 i get exactly 3
bytes with a value of 0x02.

We could use a larger field, say 20 bytes, to higher the statistical
probability of a duplication.... but didn't solve the problem.
Any idea on how to resolve this?

10 IN-DATA. INPUT
15 IN-PRESFUNC1 PIC 9(1) DISPLAY. INPUT
15 IN-FUNC1 OCCURS 1 TIMES DEPENDING ON IN-PRESFUNC1.
25 IN-INITSEP1 PIC X. INPUT
25 IN-INITSEP2 PIC X. INPUT
25 IN-INITSEP3 PIC X. INPUT
25 IN-FUNCID PIC X(20). INPUT
25 IN-DATA1 PIC X(10). INPUT
25 IN-DATA2 PIC S9(15)V9(3) DISPLAY.INPUT
25 IN-ENDSEP1 PIC X. INPUT
25 IN-ENDSEP2 PIC X. INPUT
25 IN-ENDSEP3 PIC X. INPUT
15 IN-PRESFUNC2 PIC 9(1) DISPLAY. INPUT
15 IN-FUNC2 OCCURS 1 TIMES DEPENDING ON IN-PRESFUNC2.
25 IN-INITSEP11 PIC X. INPUT
25 IN-INITSEP21 PIC X. INPUT
25 IN-INITSEP31 PIC X. INPUT
25 IN-FUNCID1 PIC X(20). INPUT
25 IN-DATA11 PIC X(10). INPUT
25 IN-DATA21 PIC S9(15)V9(3) DISPLAY.INPUT
25 IN-ENDSEP11 PIC X. INPUT
25 IN-ENDSEP21 PIC X. INPUT
25 IN-ENDSEP31 PIC X. INPUT

thanks
Carlo Folini

Crasch · Guest

Hi,
the idea is to have a dual way of separating data.
The first is based on "DEPENDING ON " construct, so the area is
perfectly defined and there's no need for a separator.
The second is based on separators. Actually this approach is used by an
host transaction that forwards specific areas to the right transaction.
This transaction is very simple with fewer logic as possible.
Essentially it searches for the initial separator, looks up the
IN-FUNCID in a table to determine what transaction to call and forwards
the area 'till the end separator.
We thinked about this solution because the areas could be very complex
and hierarchical so we would like to find an easy way to get the right
area portion to pass to the transaction.
The windows part of the communication and the final transaction knows
exactly what the area is, the middle (dispatching) transaction isn't
aware of data layout.

I hope you understood what we mean.
Maybe we have to approach the problem in a different way

Thnx
Carlo

Terry Bullington [MSFT] · Guest

Would a discriminant work? If you have a field defined in a well known
position and of a well known data type (say an integer) then it could
function as a discriminant to define the layout (an length) of the data
structure. For example,

struct {
short discriminant;
char chardata1[80];
float flfield1;
char chardata2[6];
} st1;

struct {
short discriminant;
char chardata3[55];
long llongdata1;
char chardata4[89];
} st2;

the variable "discriminant" is located at the same spot regardless of which
structure is actually present. If you assign a value of 1 in discriminant
to mean, for instance, that st1 is present and a value of 2 to mean that
st2 is present you can then use the value of discriminant to determine
which transaction to call.
--------------------
From: "Crasch" <carlo.folini@gmail.com>
Newsgroups: microsoft.public.hiserver.general
Subject: Re: Area separator
Date: 8 Mar 2005 02:59:40 -0800

Hi,
the idea is to have a dual way of separating data.
The first is based on "DEPENDING ON " construct, so the area is
perfectly defined and there's no need for a separator.
The second is based on separators. Actually this approach is used by an
host transaction that forwards specific areas to the right transaction.
This transaction is very simple with fewer logic as possible.
Essentially it searches for the initial separator, looks up the
IN-FUNCID in a table to determine what transaction to call and forwards
the area 'till the end separator.
We thinked about this solution because the areas could be very complex
and hierarchical so we would like to find an easy way to get the right
area portion to pass to the transaction.
The windows part of the communication and the final transaction knows
exactly what the area is, the middle (dispatching) transaction isn't
aware of data layout.

I hope you understood what we mean.
Maybe we have to approach the problem in a different way

Thnx
Carlo

	Windows Server Forum Index -> Host Integration Server	All times are GMT
Page 1 of 1