IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Need to summ the key matching fields


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
ibmmainframesyntel

Active User


Joined: 26 Feb 2007
Posts: 126
Location: Chennai

PostPosted: Tue Aug 26, 2008 1:16 pm
Reply with quote

Field attributes

RLSE-PART PIC X(10).
RLSE-TYPE PIC X(02)
RLSE-ORDER-DATE PIC 9(08).
RLSE-ORDER-QTY PIC S9(09) COMP-3.
RLSE-SUPPLIER-STATUS PIC S9(09) COMP-3.

Input file1 - LRECL-10,FB
--------
position 1-10 RLSE-PART

Input file2 - LRECL-5569,FB
--------
position 1-10 - RLSE-PART

position 48-49 - RLSE-TYPE

position 109-113, RLSE-SUPPLIER-STATUS

The below fields starts from the position 186 ,

05 RELEASE-DATES-AMOUNTS OCCURS 250.
10 RLSE-RELEASE-YYYYMM PIC 9(06).
10 RLSE-DATE-QTY-BUY-CODE.
15 RLSE-ORDER-DATE PIC 9(08).
15 RLSE-ORDER-QTY PIC S9(09) COMP-3.
15 RLSE-EXT-BUY-CODE PIC XX.



Using matching Part number from both files, we will look at the part type ( RLSE-TYPE = AU), we are only looking for type 'AU'.

We will look for qualities based on today date and forward in the RLSE-ORDER-DATE field take if Date > or = to current date. The date is listed as YYYYMMDD. For those fields, sum the quantity from RLSE-ORDER-QTY field. The sum will be the total forecast order.

After this, look in the RLSE-SUPPLIER-STATUS field. If the number is '0', then no calculation is needed. If the status has a negative number, then make the number positive and add to the total forecast order. If the status is positive number, then subtract from the total forecast order.

Lastly if the end forecast number (Total Forecast Order) happens to be less then '0' based on the calculation, then the Total Forecast Order will be just be 0, not a negative number.


If
input file1

PART000001
PART000002
PART000003
PART000004
PART000005
PART000006

input file2

PART000001... VU.... +5.....20080826 +1 20080826+2 20080826+3 .....
PART000002... AU.... +5.....20080825 +1 20080826+2 20080827+3 .....
PART000003... AU.... +5.....20080826 +1 20080826+2 20080826+3 .....
PART000004... AU.... -5..... 20080827 +1 20080826+2 20080826+3 .....
PART000005... AU....+5..... 20080828 +1 20080826+1 20080826-1 .....
PART000007... AU....+5..... 20080828 +1 20080826+2 20080826+3 .....


Outfile
PART000002 +0
PART000003 +1
PART000004 +11
PART000005 +0


In the outpufile,
PART000001 is not available because, RLSE-TYPE not equal to 'AU'
Back to top
View user's profile Send private message
Arun Raj

Moderator


Joined: 17 Oct 2006
Posts: 2481
Location: @my desk

PostPosted: Wed Aug 27, 2008 7:04 pm
Reply with quote

ibmmainframesyntel,

Why dont you go ahead and code a COBOL for this?

Thanks,
Arun
Back to top
View user's profile Send private message
ibmmainframesyntel

Active User


Joined: 26 Feb 2007
Posts: 126
Location: Chennai

PostPosted: Thu Aug 28, 2008 12:03 pm
Reply with quote

JCl is optimised than COBOL...
Back to top
View user's profile Send private message
Arun Raj

Moderator


Joined: 17 Oct 2006
Posts: 2481
Location: @my desk

PostPosted: Thu Aug 28, 2008 12:13 pm
Reply with quote

Quote:
JCl is optimised than COBOL

ibmmainframesyntel,

What do you really mean by the above statement? You need a JCL for executing a COBOL program. If you are referring to some SORT utility,I am afraid whether you will have to code an optimised SORT much bigger than a COBOL program for the above requirement. You have an array occurring 250 TIMES in your input file; how you are planning to handle this in SORT?

Thanks,
Arun
Back to top
View user's profile Send private message
ibmmainframesyntel

Active User


Joined: 26 Feb 2007
Posts: 126
Location: Chennai

PostPosted: Thu Aug 28, 2008 12:18 pm
Reply with quote

ibmmainframesyntel wrote:
JCl is optimised than COBOL...
Back to top
View user's profile Send private message
ibmmainframesyntel

Active User


Joined: 26 Feb 2007
Posts: 126
Location: Chennai

PostPosted: Thu Aug 28, 2008 12:21 pm
Reply with quote

Me too not aware to handle that in JCl...
I know this is possible using COBOL...
But if we got the above requirements using SORT or ICETOOL,will be best...
Back to top
View user's profile Send private message
Arun Raj

Moderator


Joined: 17 Oct 2006
Posts: 2481
Location: @my desk

PostPosted: Thu Aug 28, 2008 1:58 pm
Reply with quote

Quote:
But if we got the above requirements using SORT or ICETOOL,will be best

AFAIK, SORT cannot handle tables as COBOL does and you will have to provide the field poistions of all 250 occurrences. Do you think this is the best way?

Thanks,
Arun
Back to top
View user's profile Send private message
sampathkmn
Warnings : 1

New User


Joined: 12 Dec 2005
Posts: 31
Location: bangalore

PostPosted: Thu Aug 28, 2008 2:29 pm
Reply with quote

Most of the matching logics can be handled easily in ezytrieve with lesser lines of code than cobol..
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Fri Aug 29, 2008 12:09 am
Reply with quote

Hello,

Quote:
with lesser lines of code than cobol..
Lines of code is a very poor way to determine implementation method. . .

In fact, it may be worst way to choose how a requirement is implemented. . .
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts Rexx pattern matching on PS qualifer ... CLIST & REXX 1
No new posts File matching functionality in Easytr... DFSORT/ICETOOL 14
No new posts Concatenate 2 fields (usage national)... COBOL Programming 2
No new posts Cobol COMP-2 fields getting scrambled... Java & MQSeries 6
No new posts Converting unpacked fields to pack us... SYNCSORT 4
Search our Forums:

Back to Top