Hi,

I want to sort the following list (key seq file)

Card                          Fiid
-------                          ------
400001123456            101
400001123457            101
400001123458            101
400002000001            101
400002000002            101
400003000007            101
400004000008            101
400004000010            101

As below,

Fiid     Bin               Count
-----     ----------          --------
101     400001         3
          400002         2
          400003         1
          400004         2

It need a string operation followed by COUNT - OVER. But I'm not able
to do that with partial string. Following query doesn't work.

DECLARE bin INTERNAL A6
LIST BY FIID, BY bin:= card, COUNT(FIID over bin);

Can anyone please help? Thank you for your time.

-- Som

In article <f80bcb29-2e1b-4e4a-a2f7-21004aa057d5@35g2000yqa.googlegroups.com>, Soumyajit G <soumyajit.g@gmail.com> wrote:
>Hi,
>
>I want to sort the following list (key seq file)
>
>Card                          Fiid
>-------                          ------
>400001123456            101
>400001123457            101
>400001123458            101
>400002000001            101
>400002000002            101
>400003000007            101
>400004000008            101
>400004000010            101
>
>As below,
>
>Fiid     Bin               Count
>-----     ----------          --------
>101     400001         3
>          400002         2
>          400003         1
>          400004         2
>
>It need a string operation followed by COUNT - OVER. But I'm not able
>to do that with partial string. Following query doesn't work.
>
>DECLARE bin INTERNAL A6
>LIST BY FIID, BY bin:= card, COUNT(FIID over bin);
>
>Can anyone please help? Thank you for your time.

Simple. Change the definition of CARD in your DDL record description. 

Right now, I imagine it's similar to
        03 card TYPE CHARACTER 12.
Change it to
        03 card.
          05 bin TYPE CHARACTER 6.
          05 nex-six TYPE CHARACTER 6.
(Note that this retains the definition of 'card' as TYPE CHARACTER 12, since 
it's now a group item that encompasses 12 characters total.)

Then in your Enform program:
        LIST BY fiid, BY bin, COUNT (fiid OVER bin);

Thanks for your reply.
Due to other restriction changing the DDL is not an option.

In article <d3e495fa-fc6e-484c-bcca-fc0642676971@m25g2000yqc.googlegroups.com>, Soumyajit G <soumyajit.g@gmail.com> wrote:
>Thanks for your reply.
>Due to other restriction changing the DDL is not an option.

So change a copy of it. You clearly have read access to that data dictionary 
(if you didn't, you wouldn't be able to run Enforms against it). Make your own 
dictionary in your own subvolume, copy that record to it, and change your 
copy.

The script will be executed on production. No option for creating/
modifying ddl.

In article <f14a4a52-6719-452e-8cb1-7a439bb92d3d@26g2000yqo.googlegroups.com>, Soumyajit G <soumyajit.g@gmail.com> wrote:
>The script will be executed on production. No option for creating/
>modifying ddl.

When replying to posts in a newsgroup, please quote the relevant portion of 
the post that you're replying to, so people will know what you're talking 
about.

You can't do what you want to do with Enform unless you change the DDL as I 
described.

Your options are limited:
1. Get permission to modify the DDL.
2. Write the report program in some other language: Cobol, Tal, C, maybe even 
TACL.
3. Live with the problem.

Doug Miller wrote:
> In article <f14a4a52-6719-452e-8cb1-7a439bb92d3d@26g2000yqo.googlegroups.com>, Soumyajit G <soumyajit.g@gmail.com> wrote:
> 
>>The script will be executed on production. No option for creating/
>>modifying ddl.
> 
> 
> When replying to posts in a newsgroup, please quote the relevant portion of 
> the post that you're replying to, so people will know what you're talking 
> about.
> 
> You can't do what you want to do with Enform unless you change the DDL as I 
> described.
> 
> Your options are limited:
> 1. Get permission to modify the DDL.
> 2. Write the report program in some other language: Cobol, Tal, C, maybe even 
> TACL.
> 3. Live with the problem.

If the people who control the DDL resist changing the existing record definition, keep in mind that there are other similar ways which might be acceptable to them.

For instance, perhaps they would be willing to add a completely new record definition for the same file that describes the fields in the way Doug mentioned in his earlier solution to the problem.  Of course, they might object to having two definitions of the same file because of the danger that the two definitions might fall out of sync with each other.  Or maybe they would be willing to add a REDEFINES for the CARD field.

Perhaps they would be willing to add a completely new record definition for a new file (a temporary work file for this report) that describes just the fields needed in the new report in the way Doug described.  The ENFORM for the report would use a FIND command to extract the data from the original file into the work file, then a LIST command to produce the report from the work file.  Of course that would make it take a little longer to run the report than doing it directly, but the difference might not be large enough to be a problem.

I know you said that there was no ability to create or modify DDL in production, but does that just mean that you cannot modify the production DDL dictionary, or does it mean the DDL program is not available at all?  If it just means that you cannot modify the production DDL, then consider this approach:  As part of the report job, create a temporary DDL dictionary that describes the file in the way Doug suggested.  The report job might use DDL to open the production dictionary, use the DDL ?SHOW command to display the layout of the RECORD you need to use, capture that display into a TACL variable, use a TACL macro to get the current data file name and the offset and data types of each field you need to use in your report, use that information to construct a RECORD definition to define the record containing just those fields and the appropriate FILLER to get their offsets correct (except change the CARD field to the way Doug suggested it be described), use DDL to create the 
temporary DDL dictionary from this new RECORD description, and finally run the ENFORM report using the temporary DDL dictionary.  That might seem like a lot of processing, but extracting information from a DDL dictionary and creating a DDL dictionary containing one simple record definition would not take more than a few seconds to run.  You might think it would be easier to use an OUTPUT statement to get DDL source for the RECORD you need, but if that RECORD definition refers to DEFs for the descriptions of some of its fields, I think there is no automatic way to track down all the DEFs you need to DDL compile that RECORD into a new dictionary.

Without knowing all the technical and political constraints you have to work within, we probably cannot think of all possible approaches that might be workable.  If the people responsible for the DDL for the file want to help you get that report working, they probably would agree to either Doug's original suggestion for modifying the DDL describing the record, or one of the first two possibilities I mention above, or some other similar approach that they can think of.  Have you talked with them about it?

If you are working in an environment where the people in charge of the NonStop system support it only grudgingly or are trying to push it out of the data center, their main motivation might be to find excuses to keep you from doing the report on the NonStop system so that they have more ammunition for putting projects onto their more-favored platform, whatever it is.  In such an environment, you cannot do things the right way and have to settle for poor approaches.

If none of the above approaches (including Doug's suggestions) can be used in your environment, try to tell us what the restrictions are that you must work within, or what kind of things you are allowed to do, and we will try to think of some other approach that can be used.  If this report is only a one-time report (not a permanent addition to the collection of report jobs), mention that -- it might affect how to solve the problem.

On Jan 9, 8:00=A0pm, Keith Dick <KeithD...@earthlink.net> wrote:
> Doug Miller wrote:
> > In article <f14a4a52-6719-452e-8cb1-7a439bb92...@26g2000yqo.googlegroup=
s.com>, Soumyajit G <soumyaji...@gmail.com> wrote:
>
> >>The script will be executed on production. No option for creating/
> >>modifying ddl.
>
> > When replying to posts in a newsgroup, please quote the relevant portio=
n of
> > the post that you're replying to, so people will know what you're talki=
ng
> > about.
>
> > You can't do what you want to do with Enform unless you change the DDL =
as I
> > described.
>
> > Your options are limited:
> > 1. Get permission to modify the DDL.
> > 2. Write the report program in some other language: Cobol, Tal, C, mayb=
e even
> > TACL.
> > 3. Live with the problem.
>
> If the people who control the DDL resist changing the existing record def=
inition, keep in mind that there are other similar ways which might be acce=
ptable to them.
>
> For instance, perhaps they would be willing to add a completely new recor=
d definition for the same file that describes the fields in the way Doug me=
ntioned in his earlier solution to the problem. =A0Of course, they might ob=
ject to having two definitions of the same file because of the danger that =
the two definitions might fall out of sync with each other. =A0Or maybe the=
y would be willing to add a REDEFINES for the CARD field.
>
> Perhaps they would be willing to add a completely new record definition f=
or a new file (a temporary work file for this report) that describes just t=
he fields needed in the new report in the way Doug described. =A0The ENFORM=
 for the report would use a FIND command to extract the data from the origi=
nal file into the work file, then a LIST command to produce the report from=
 the work file. =A0Of course that would make it take a little longer to run=
 the report than doing it directly, but the difference might not be large e=
nough to be a problem.
>
> I know you said that there was no ability to create or modify DDL in prod=
uction, but does that just mean that you cannot modify the production DDL d=
ictionary, or does it mean the DDL program is not available at all? =A0If i=
t just means that you cannot modify the production DDL, then consider this =
approach: =A0As part of the report job, create a temporary DDL dictionary t=
hat describes the file in the way Doug suggested. =A0The report job might u=
se DDL to open the production dictionary, use the DDL ?SHOW command to disp=
lay the layout of the RECORD you need to use, capture that display into a T=
ACL variable, use a TACL macro to get the current data file name and the of=
fset and data types of each field you need to use in your report, use that =
information to construct a RECORD definition to define the record containin=
g just those fields and the appropriate FILLER to get their offsets correct=
 (except change the CARD field to the way Doug suggested it be described), =
use DDL to create the
> temporary DDL dictionary from this new RECORD description, and finally ru=
n the ENFORM report using the temporary DDL dictionary. =A0That might seem =
like a lot of processing, but extracting information from a DDL dictionary =
and creating a DDL dictionary containing one simple record definition would=
 not take more than a few seconds to run. =A0You might think it would be ea=
sier to use an OUTPUT statement to get DDL source for the RECORD you need, =
but if that RECORD definition refers to DEFs for the descriptions of some o=
f its fields, I think there is no automatic way to track down all the DEFs =
you need to DDL compile that RECORD into a new dictionary.
>
> Without knowing all the technical and political constraints you have to w=
ork within, we probably cannot think of all possible approaches that might =
be workable. =A0If the people responsible for the DDL for the file want to =
help you get that report working, they probably would agree to either Doug'=
s original suggestion for modifying the DDL describing the record, or one o=
f the first two possibilities I mention above, or some other similar approa=
ch that they can think of. =A0Have you talked with them about it?
>
> If you are working in an environment where the people in charge of the No=
nStop system support it only grudgingly or are trying to push it out of the=
 data center, their main motivation might be to find excuses to keep you fr=
om doing the report on the NonStop system so that they have more ammunition=
 for putting projects onto their more-favored platform, whatever it is. =A0=
In such an environment, you cannot do things the right way and have to sett=
le for poor approaches.
>
> If none of the above approaches (including Doug's suggestions) can be use=
d in your environment, try to tell us what the restrictions are that you mu=
st work within, or what kind of things you are allowed to do, and we will t=
ry to think of some other approach that can be used. =A0If this report is o=
nly a one-time report (not a permanent addition to the collection of report=
 jobs), mention that -- it might affect how to solve the problem.




Thank you all for putting your thoughts. I was hoping there is some
other tricks to get that data without much modification. Anyways, I
had to put a REDEFINE and that was easy. I think it's is shortcoming
on Enform's part that it doesn't allow to aggregate over partial
string. It would have been very useful.

In article <4dda171c-f4a6-40c6-9438-1b84a36c6595@m25g2000yqc.googlegroups.com>, Soumyajit G <soumyajit.g@gmail.com> wrote:
>
>Thank you all for putting your thoughts. I was hoping there is some
>other tricks to get that data without much modification. Anyways, I
>had to put a REDEFINE and that was easy.

You said you couldn't change the DDL -- how did you manage to do a REDEFINE?

> I think it's is shortcoming
>on Enform's part that it doesn't allow to aggregate over partial
>string. It would have been very useful.

It *does* allow you to aggregate over a partial string -- if you define your 
data properly.