How to move a PDA in a byte container?

, , ,
1

Hi everybody.

Products: Nat 4.2 Ada 7.x

I’m facing the following task:

To optimize a massive batch processing, different Natural PDAs, holding already processed data, should be temporarily stored in adabas. Thus adabas will act as a “cache”.

Additional requirements:

  • The general usage of the PDAs should not be affected.
  • RESET MYPDA should work (type specific initial values)
  • MYPDA.NAME := ‘brian’ should work (so MYPDA must stay on Level 1)
  • CALLNAT 'SUBPRG´ MYPDA should work as before

I started with the cache FDT:

PE 1 CACHE 80
2 BYTE-CONTAINER B 125

Giving a byte container of 10’000 bytes.

The user view is

1 CACHE-VIEW
2 BYTE-CONTAINER B 125 (1:80)
2 REDEFINE BYTE-CONTAINER
3 BYTE-CHUNK B10000

When it comes to the Natural PDAs it becomes tricky. The idea was to make some kind of redefine in order to code

CACHE-VIEW.BYTE-CHUNK := MYPDA.BYTES

As mentioned before, the usage of MYPDA should not be affected.

My first try was to redefine the Level 1 MYPDA. This causes a NAT 207.
Then I tried to do

1 MYPDA
2 BYTES B 1200
2 REDFEINE BYTES
3 NAME A30
3 BIRTHDAY D

This causes a RESET MYPDA to initialize all data with x’00’.

Then the version
1 MYPDA
2 BYTES B 1200
2 REDFEINE BYTES
3 MYPDA_STRUCT
4 NAME A30
4 BIRTHDAY D

Works, but all RESET Statements either explicit or implicit must be changed to RESET MYPDA.MYPDA_STRUCT.

To summarize it: I didn’t find a way in Natural to do it AND fulfill the above mentioned requirements.

What I really need is something like “memcpy” (or MVCL) to move a chunk of bytes.
My current strategy is to use the CALL INTERFACE4 and let a “C”-program do the job.

Are there any other hints to solve this task?
Thx for any suggestions
Christian

2

Hi Christian

Not sure what you are trying to do in to do; but have you tried:

1 mypda view of…
2 name (a30)
2 city (a25)
:::
1 redefine mypda
2 bytes (b1200)

etc.

When you say " CALLNAT 'SUBPRG´ MYPDA should work as before "; I presume there is a lot of code that uses MYPDA. True?

Now you want to write this data to adabas records. Still correct?

Could you try describing your problem a bit more; in particular, what is “fixed” by existing code, and what is available for “playing” by restructuring or recoding.

steve

3

Hi Steve.

Good to know that there are other people working on a sunday ;-).

All your assumptions are right.
The goal is: minimum changes on existing code, in order to avoid
extensive test-cycles.

Your idea to redefine the View like the structure of the PDAs has two
problems in my point of view:

  1. Each PDA must be explictly redefined inside the view.
  2. If the PDA changes, one has to remember the redefinition in the view.

You are also right with the assumption that there is a lot of code involved.

Based on this I would like to do

/* Move Structure to ByteChunk
CALL INTERFACE4 ‘MOVST2BY’ VIEW.BYTE-CHUNK MYPDA

/* Move ByteChunk to Structure
CALL INTERFACE4 ´MOVBY2ST’ MYPDA VIEW.BYTE-CHUNK

Using these two functions I could forget all kind of redefinition.
The only aspect is, that I’ll leave Natural with this technique.

Do you think this is “legal” way to solve my problem?
Christian

4

Hi Christian,

I’m actually browsing the forum because of a similar goal.
I’d like to pass on the content of an individual PDA to a module that should encapsulate various web service calls, let’s call it ‘N2J’ for short (Natural to Java). This module should make sure that the xml message is constructed and the response parsed correctly, and it should hold methods that are always used when a webservice call is to be made from inside Natural. Lets say we already have several copycodes and PDAs, like C1 / PDA-1, C2 / PDA-2, … originally generated by the XML toolkit, to build the XML according to the requirements of the corresponding webservice.

Now I’d like to ‘hide’ this XML serialization and parsing in this ‘N2J’ capsule.
I’d like to be able to pass on the data to the ‘N2J’ capsule without having to pass every individual PDA when calling the ‘N2J’ capsule. I’d like to avoid having to say 'CALLNAT ‘N2J’ PDA-1 PDA-2 PDA-3.
I’d rather like to say: CALLNAT ‘N2J’ N2J-A.

What I’ve thought of, but not yet tried: Would it be possible to move the complete PDA into a dynamic string of format (A) or (B), defined in a PDA like N2J-A, named like ‘INPUT-DATA’ . Also the PDA should contain the name of the PDA and the serialization copycode.
Then the ‘N2J’ capsule could call a copycode looking like that


MOVE &1& TO &2&
PERFORM  &3&

where &1& would be INPUT-DATA, &2& would be the PDA name, &3& would be the subroutine name defined inside the serialization copycode.
(Maybe a DECIDE would also do, and I assume I’ll have to define the PDAs in the ‘N2J’ module locally anyway, but that wouldn’t be a problem, there aren’t that many.)

I think if one can write / read the content of a PDA or LDA to / from a workfile, it should be possible to move this content to a dynamic variable as well? Or am I wrong?
I am curious how you get on with your goal, and hope this idea might also help you, hopefully I don’t lead you on a wrong track :wink:

5

Hi Eva.

Thx for your reply. Currently, I stay with my idea to implement 3-GL MOVE.

I spent some time thinking about your problem.

  • As I unterstand you would like to call ‘N2J’ with different PDAs.
  • Based on the provided PDA your Module ‘N2J’ should react differently
    and do a PDA specific task.
  • You stated, that you habe a limited number of PDAs which should be
    handled.

Do you know the Natural mechanismen of “optional parameters”?

On the Call-Level you can skip PDAs by coding “nX”

CALLNAT ‘N2J’ PDA-1 1X PDA-3 /* general form nX with 1<= n <= 4096.

1X means 1 Parameter is not provided.

Inside the module ‘N2J’ you can test if a PDA was provided.

DEFINE DATA
PARAMETER USING PDA-1
PARAMETER USING PDA-2
PARAMETER USING PDA-3
END-DEFINE

/* Test which Parameter was provided?
DECIDE FOR FIRST CONDITION
WHEN PDA-1 SPECIFIED
PERFORM SR-PROCESS-PDA-1
WHEN PDA-2 SPECIFIED
PERFORM SR-PROCESS-PDA-2
WHEN PDA-3 SPECIFIED
PERFORM SR-PROCESS-PDA-3
WHEN NONE
IGNORE /* fooled by the caller
END-DECIDE
…
END /* N2J

I guess this is

  • easy to understand
  • you can work on the real PDAs and need no redefine.
  • New PDAs can easily added (always an the end of the PDAs Definitions
    inside N2J! otherwise already present CALLNATs must be inspected)
  • You have no need to copy the PDA into a bigbytefield on the calling Layer
    in order to have a uniform parameter definition in N2J.
  • and the recopy (inside N2J) from the bigbytefield in the specific PDA
    can be omitted as well.

The only problem I see is discipline!
The relative position of a PDA is fix. Therefore you must always skip
the right number of parameters using nX.

Hope my ideas will help you.
cu Christian

IF PDA-1 SPECIFIED
PERFORM PROCESS_PDA-1

6

Hello Christian,

thanks very much for your info regarding the optional parameters. I know optional parameters but I wasn’t aware that it is possible to skip whole PDAs. I’ll try this out first thing tomorrow :slight_smile:
Actually the idea was to pass one dynamic length parameter as well as another field containing the name of the PDA resp. Module. Inside N2J, the the content of the dynamic parameter would have to be moved to the named PDA. which would have to be locally defined there. However, to pass the PDAs themselves with ‘nX’ for the PDAs to be omitted, is much clearer.